The Security criteria, one by one.

The criteria document says the common criteria are enough on their own to judge security. The other four categories each add their own criteria on top of the common set, never instead of it. So a report that covers Availability alone is still tested against all thirty-three common criteria.

The first five series follow the COSO 2013 internal-control framework, the same seventeen principles used in financial-reporting control work. The last four, CC6 to CC9, are supplemental criteria the AICPA added for systems: access, operations, change and risk mitigation.

A criterion is a goal, not a control. Each criterion carries points of focus that describe what it usually involves; they help you design controls, but the auditor does not require every point to be met.

CC1: control environment

1. CC1.1
   Integrity and ethicsLeaders show they expect honest conduct. Example: a code of conduct every hire acknowledges, with a route for reporting breaches.
2. CC1.2
   Independent oversightSomeone above management watches how controls are run. Example: a board or advisory group that reviews security at a set interval.
3. CC1.3
   Structure and authorityReporting lines and responsibilities are clear. Example: an org chart and a named owner for security.
4. CC1.4
   Competent peopleYou hire, train and keep people able to do the work. Example: background checks where lawful, plus annual security training.
5. CC1.5
   AccountabilityPeople answer for their control duties. Example: control duties in job descriptions and performance reviews.

CC2: communication and information

1. CC2.1
   Useful informationThe data that controls depend on is relevant and reliable. Example: an asset inventory kept current from the cloud console.
2. CC2.2
   Internal communicationStaff learn the objectives and their part in them. Example: published policies and an onboarding session on reporting incidents.
3. CC2.3
   External communicationCustomers and others hear what affects them. Example: a public security page, a support channel and customer notices of changes.

CC3: risk assessment

1. CC3.1
   Clear objectivesGoals are specific enough to find the risks to them. Example: written service commitments and system requirements.
2. CC3.2
   Identified and analysed risksRisks across the company are listed and rated. Example: a risk register reviewed and re-scored at least yearly.
3. CC3.3
   Fraud riskYou consider how someone could misuse the system on purpose. Example: a fraud scenario section in the risk assessment.
4. CC3.4
   Significant changeNew products, vendors or leaders trigger a fresh look at risk. Example: a change in the business prompts a risk review entry.

CC4: monitoring activities

1. CC4.1
   Ongoing and separate evaluationsYou test whether controls are present and working. Example: an internal control self-check or an independent review.
2. CC4.2
   Deficiencies reported and fixedGaps reach someone who can fix them, promptly. Example: findings tracked as tickets with owners and reported to leadership.

CC5: control activities

1. CC5.1
   Controls that answer risksEach important risk has a control that reduces it. Example: a risk register column naming the mitigating control.
2. CC5.2
   Technology controlsGeneral IT controls support the rest. Example: baseline configurations for cloud accounts and laptops.
3. CC5.3
   Policies put into practicePolicies say what is expected; procedures make it happen. Example: an approved policy set with owners and a review date.

1. CC6.1
   Access security architectureProtected assets sit behind access controls. Example: single sign-on with multi-factor authentication for production.
2. CC6.2
   Registration before accessUsers are approved before they get credentials, and removed when they leave. Example: a ticketed request and a leaver checklist.
3. CC6.3
   Role-based changesAccess is granted, changed and taken away by role, with least privilege. Example: quarterly access reviews per system.
4. CC6.4
   Physical accessOnly authorised people enter sensitive places. Example: badge control at the office, and reliance on the cloud provider for data centres.
5. CC6.5
   Disposal of assetsDevices are wiped or destroyed before protection ends. Example: certified wiping of returned laptops.
6. CC6.6
   Outside threatsThe boundary is defended against outsiders. Example: firewall rules, a web application firewall and closed admin ports.
7. CC6.7
   Data in motionData moves only to authorised places and is protected on the way. Example: TLS everywhere and blocked removable media.
8. CC6.8
   Malicious softwareUnauthorised or harmful code is stopped or caught. Example: endpoint protection on every laptop and signed deployments.

CC7: system operations

1. CC7.1
   Finding vulnerabilitiesYou detect weak configurations and new flaws. Example: scheduled vulnerability scans with fix deadlines by severity.
2. CC7.2
   Watching for anomaliesComponents are monitored for signs of attack, failure or error. Example: centralised logs with alerts.
3. CC7.3
   Judging security eventsEvents are triaged to see if they are incidents. Example: an on-call runbook with severity levels.
4. CC7.4
   Responding to incidentsA defined plan contains, fixes and communicates incidents. Example: an incident response plan and post-incident reviews.
5. CC7.5
   Recovering from incidentsYou restore normal service after an incident. Example: recovery steps and lessons logged against each incident.

CC8: change management

1. CC8.1
   Controlled changeA change to systems, code, data or written procedure is requested, reviewed by someone other than its author, tested, approved and logged before it goes live. Example: pull requests with a required reviewer and passing tests.

CC9: risk mitigation

1. CC9.1
   Business disruptionYou plan for events that could stop the business. Example: a continuity plan and insurance reviewed by leadership.
2. CC9.2
   Vendors and partnersThird-party risk is assessed and managed. Example: a vendor inventory with a yearly review of key vendors' reports.

• CC1. Signed code-of-conduct acknowledgements, training records, board or leadership minutes.
• CC2 and CC3. The policy set, the risk register and the date it was last reviewed.
• CC4 and CC5. Results of internal checks, and tickets showing how findings were closed.
• CC6. Lists of joiners, leavers and users per system, plus dated access reviews.
• CC7. Scan results, alert configuration and the incident log with its follow-ups.
• CC8 and CC9. The full change list for the period, the vendor inventory and vendor reviews.

• OverviewTrust Services CriteriaThe five categories, with CC1 to CC9 read as questions your controls answer.
• AvailabilityThe Availability categoryA1.1 to A1.3: capacity, protection and tested recovery.
• ConfidentialityThe Confidentiality categoryC1.1 and C1.2: identifying, protecting and disposing of confidential data.
• PrivacyThe Privacy categoryP1 to P8: notice, choice, collection, use, access, disclosure, quality, monitoring.
• Processing IntegrityThe Processing Integrity categoryPI1.1 to PI1.5: complete, valid, accurate and timely processing.

Sources: AICPA, TSP section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (revised points of focus); COSO, Internal Control: Integrated Framework (2013). Example controls are illustrative.