The AICPA has released a draft of the revised Trust Services Criteria (TSC) for comment, with the final version expected in 2027. These new criteria will apply to any report issued after December 31, 2027. While the draft may still change, this checklist will help your team prepare effectively.
This checklist outlines steps your compliance manager can take now: inventory controls, plan mapping, address the removal of COSO references, and anticipate new AI points of focus. Each item has a clear done/not-done state and a description of what "good" looks like.
Prerequisites
Before you begin, ensure you have:
- Your current SOC 2 system description and control matrix, mapped to the existing criteria.
- Your most recent SOC 2 report and any noted exceptions.
- A named owner for the transition, ideally someone who can involve engineering, security, and legal teams.
- A list of which trust services categories are in scope for your report.
- A working relationship with your audit firm. Ask them how they plan to handle the transition.
The Checklist
1. Confirm which categories are in scope and which will change.
Security, Availability, Processing Integrity, Confidentiality, and Privacy remain. Processing Integrity and Privacy are mostly unchanged. The most disruption occurs in the Common Criteria, Availability, and Confidentiality.
Done when: you have a one-page scope summary showing each in-scope category and a high-level impact rating.
Good looks like: the team can state in two sentences why Privacy needs little rework while Common Criteria needs a lot.
2. Build a crosswalk from current criteria to the revised draft.
The Common Criteria consolidate from 33 to 21 in the current draft, and references shift. Logical and physical access moves from CC6.1 through CC6.8 to CC5.1 through CC5.6. Don't rely on memory.
Done when: every existing control has a mapped destination criterion, or a documented note that it maps to none.
Good looks like: a living spreadsheet with old reference, new reference, control ID, and owner. Mark it "draft-based" and version it.
3. Flag controls that must be split, merged, or relabeled.
Use the new criteria titles as your filter. Each criterion now carries a short title describing its objective, making this faster than parsing paragraphs.
Done when: each control is tagged split, merge, relabel, or no change.
Good looks like: no control is tagged "unknown." If it is, someone owns resolving it.
4. Decide how you'll treat COSO now that the reference is gone.
The COSO Principles reference has been removed. If your internal control program was built on COSO, you can keep using it as a structure. The criteria just no longer point to it directly.
Done when: you've documented a decision: retain COSO as your internal structure, or restructure around the new criteria.
Good looks like: your control framework document explains its organizing logic without depending on the criteria to supply it. Auditors should be able to follow your structure either way.
5. Update governance language and evidence for the Control Environment.
CC1.0 shrinks from five criteria to two, and "Board of Directors" is replaced with "Those Charged with Governance." That term covers a board, a committee, or another body.
Done when: you've identified who your governing body is and updated charters, meeting minutes templates, and policy approval records to match.
Good looks like: a reviewer can see who provides oversight of security without guessing, and the evidence trail names that body consistently.
6. Test your risk program against the establish, execute, monitor lifecycle.
CC3.0 now splits into three criteria that follow the life cycle of a risk management program. Fraud risk and changes to control are no longer standalone requirements, though they appear in the points of focus.
Done when: your risk methodology document, risk register, and risk review records each clearly map to one of the three phases.
Good looks like: you can show a program that's established (policy and methodology), executed (assessments performed), and monitored and improved (reviews leading to changes).
7. Rebuild incident response documentation around a single criterion.
The former CC7.2 through CC7.5 collapse into CC6.2 Incident Response Programs.
Done when: your incident response plan, test records, and post-incident reviews all trace to the single criterion.
Good looks like: one coherent program narrative, not four separate artifacts that were each written to satisfy a different criterion.
8. Separate change management by system component.
The former CC8.0 splits into CC7.1 (infrastructure), CC7.2 (acquired software), and CC7.3 (internally developed software). If you buy software and also build it, your obligations are now stated separately.
Done when: your change management procedures and sample populations are segmented by those three component types.
Good looks like: an auditor can pull a change ticket and see immediately which of the three applies and what evidence supports it.
9. Re-scope Availability and Confidentiality controls.
A1.2 splits into Environmental Protections (A1.2) and Resilience Capabilities (A1.3). C1.1 splits into Classification and Inventory (C1.1) and Maintenance of Confidential Data (C1.2).
Done when: physical safeguards are documented apart from resilience planning, and you can produce both a confidential data inventory and evidence of ongoing protection.
Good looks like: a current data inventory with owners, plus evidence that protection is maintained over time, not just established once.
10. Evaluate AI components against the new points of focus.
The AICPA didn't add AI-specific criteria. It added AI-specific points of focus covering training data manipulation, adversarial inputs, model misuse, reliability, bias, unintended consequences of outputs, prompt manipulation, and data poisoning.
Done when: you have an inventory of AI components in your system and a documented risk assessment against each point of focus.
Good looks like: AI risks sit inside your existing risk register and control set, not in a separate document nobody maintains. For customers who want more, a SOC 2 examination combined with an AIUC-1 report is one path. Adopting a framework such as ISO/IEC 42001 or the NIST AI Risk Management Framework within your security and risk programs is another.
Common Mistakes
- Treating the draft as final. It isn't. Build your crosswalk so it can absorb changes.
- Memorizing new numbers. References have shifted, including some that now reuse numbers with different meanings. Always cite the title alongside the number.
- Assuming removal means loss of coverage. The old CC5.0 control activities criteria were removed because other criteria already cover their substance. You still need those controls.
- Treating AI points of focus as a checklist. They guide how you think about AI risk within criteria that already apply. They don't create new standalone requirements.
- Waiting for your auditor to drive. Control mapping, gap analysis, and readiness work take time.
Next Steps
Start with items 2 and 3, since the crosswalk drives everything else. Schedule a conversation with your audit firm about their transition approach and evidence expectations. Track the AICPA's progress toward the 2027 release and update your crosswalk when the draft changes. If you use AI in your service, begin item 10 now, because customers are already asking.
