Trustero Curated Content v4.2
Trustero customers now have the option to use an updated set of controls and policies. Customers who are using curated content and not in the middle of an audit and/or are heavily relying on Audit Scan are strongly encouraged to upgrade their content. Schedule your controls upgrade. Customers will need to make small manual updates to three policies.
This update includes a streamlined, clearer core set of information security controls:
- More concrete and actionable control objectives
- Simpler, shorter required evidence
- More specific test procedures
Policies have minor changes to ensure the policy and updated controls are in sync and that the Audit Scan control-matches-policy check passes.
By the Numbers
Control changes:
- 54 total: all 50 SOC 2 controls plus some additional information security controls for other frameworks
- 1 name
- 11 objectives
- 1 general guidance
- 45 required evidence fields
- 48 test procedures fields
- 1 new control: BC02. This clarifies the need to do a Disaster Recovery Plan. This was already covered by other controls, it is just more explicit now.
Policies: 3 updated to better align with control objectives
Control Objective Changes
Previous control objectives were sometimes written to be very flexible and somewhat abstract. That was great for accommodating a wide range of control implementations, but made it difficult to implement some controls in the first place, because it wasn’t clear what should be done.
Example: IAM04
Before: The granting, provisioning and use of privileged access rights is restricted and managed.
After: Privileged (e.g., admin-level) access rights are restricted and monitored.
Control Required Evidence Changes
Previously required evidence sometimes included details about why the evidence was required and which fields it should contain. It is now stripped down and focuses just on the type of evidence. Details about which fields should be present are now found in the test procedures field. This should make them easier and quicker to read.
Example: IAM06
Before:
- Configuration screenshots or reports from each primary system, detailing the password policy requirements, including minimum length, character complexity, and expiration or change frequency.
- User lists from each primary system that include MFA status for each user, indicating whether MFA is enabled.
After:
- User password configuration screenshots or reports from each primary system
- User lists from each primary system that include MFA status for each user
Control Test Procedures Changes
Previously some of the test procedures were subjective. We’ve updated many of them to be much more concrete and objective.
Example: CM01
Before:
Inspect formal records, such as issue or ticket tracking systems, to validate that a formal change management process is followed. This includes validating that the system is used to track the progression of each change from submission to completion (e.g., to do, in progress, blocked, ready to review, merged and done).
After:
- Validate that the system is used to track the progression of each change from submission to completion (e.g., to do, in progress, blocked, ready to review, merged and done).
- Validate Secure Development Policy outlines the rules and formal processes for managing changes.
Policy Changes
Three policies have updates to make sure they align with updated control objectives. See details linked below on changes that you should make to your policies.