SOC 2 Type 2 : how each Common Criterion is tested in a Secure SDLC

In April I published a mapping of the SOC 2 Type 2 Common Criteria to Secure SDLC requirements. That article answers the question “which criterion touches which SDLC phase”. This one answers the question that comes right after it in every readiness project: how does the auditor actually test each criterion, and what makes a sample pass or fail?

This article is written from the auditor’s side of the table. For each Common Criterion you will find what the criterion asks for, how it is tested in a Type 2 engagement, an example of evidence that passes, an example that produces an exception, and the exceptions that come up most often. The phase mapping and the evidence checklist from the original article still apply, so read that one first if you haven’t.

A note on terms. A SOC 2 report is an attestation issued by a licensed CPA firm under AICPA standards. It is not a certification, even though most people (me included, in the earlier article) use that word. The criteria referenced here are the 2017 Trust Services Criteria with the revised points of focus the AICPA published in 2022. Points of focus are guidance and not mandatory requirements. Not every point has to be covered by a control, and your auditor may weigh them differently.

 

How a Type 2 auditor thinks

A Type 1 report asks whether controls are suitably designed at a single point in time. A Type 2 report adds a second question: did those controls operate effectively throughout the review period? Most periods run 6 to 12 months. First reports sometimes use a shorter period, occasionally as short as 3 months.

That second question changes the work completely. The auditor stops reading your policies and starts asking for populations. A population is the complete list of every occurrence of a control during the period. Every production deployment, every new hire, every terminated account, every critical vulnerability. The auditor first checks that the population is complete and accurate, because a sample drawn from an incomplete list proves nothing. Then a sample is selected, and every item in it needs a full evidence trail.

Inquiry alone is not sufficient evidence of operating effectiveness. When an engineering lead says “we always do that”, the auditor will ask for the document, the log entry or the ticket that shows it.

Sample sizes depend on how often a control runs and on the risk the auditor assigns to it. Each audit firm uses its own methodology, so treat the numbers below as an illustration and confirm the real ones with your auditor. They come from a published Strike Graph sampling guide.

Control frequency	Samples, moderate risk	Samples, high risk
Monthly	2	3
About 25 times per year	3	5
Weekly	8	10
Large population (more than 365 occurrences)	45	60
Automated control (any frequency)	1	1

The last row matters most for the SDLC. An automated control, such as branch protection that technically blocks a merge without approval, can often be tested with one sample plus evidence that its configuration did not change during the period. A manual control that runs many times a day can need 45 to 60 samples. That is the strongest practical argument for moving SDLC controls into the pipeline.

When a sample fails, the auditor records an exception, also called a deviation, and many* deviations get to a non-conformity. One exception does not automatically lead to a qualified opinion. The auditor considers how many* exceptions there were, whether other controls compensate, and whether the criterion was still met. Every exception still appears in the tests of controls section of the report, next to management’s response, and your customers will read it.

CC1: Control environment

Summary: The control environment is the foundation the other criteria sit on. It asks whether leadership sets the tone on integrity and ethics, whether a board or equivalent body oversees internal control, whether roles and reporting lines are clear, whether the company hires and keeps competent people, and whether individuals are held accountable for their part in internal control.

What the criterion asks. CC1.1 to CC1.5 cover commitment to integrity and ethical values, board oversight, organizational structure and reporting lines, competence of personnel, and accountability. For the SDLC this means that someone owns the process and has the authority to enforce it.

How it is tested. CC1 controls are mostly annual or event driven, so samples are small. The auditor inspects the SDLC policy and its approval record, the org chart, job descriptions for security and engineering leads, and code of conduct acknowledgments. Then comes the question that separates design from operation: “Show me a time during the period when security actually used that authority.”

Passing evidence example: Secure SDLC policy version x.y was approved in January, inside the review period, and names the Head of Product Security as owner. A release ticket from June shows the Product Security lead blocked a release because of an open critical finding. The release went out nine days later, after the fix was verified.

Exception example: The policy names an owner who left the company in March. Nobody was assigned until the auditor asked about it in September. For six months the control had no owner.

Common exceptions: Policies not reviewed within the interval the policy itself defines, for example “reviewed annually” with the last approval 18 months ago. New hires who did not sign the code of conduct within the required time. Engineering performance reviews that were scheduled but never documented.

CC2: Communication and information

Summary: This criterion is about how information flows. The organization has to produce and use reliable information to run its controls, tell its own people what their control responsibilities are, and communicate the relevant matters to customers, vendors and other outside parties.

What the criterion asks. CC2.1 requires relevant, quality information to support internal control. CC2.2 requires internal communication of objectives and responsibilities. CC2.3 covers communication with external parties such as customers and vendors.

How it is tested. The auditor takes the population of employees and contractors active during the period, including new joiners, and samples it. For each person they look for a dated policy acknowledgment and a training completion record. If a policy changed during the period, they check that the new version was communicated. For CC2.3 the auditor looks at how customers learn about security commitments, system changes and incidents. A trust page, release notes, contract terms or a status page can all serve as evidence.

Passing evidence example: All 25 sampled engineers have a learning platform record showing secure coding training completed within 30 days of their start date or within the annual cycle. Each one also has a timestamped acknowledgment of SDLC policy version 3.1.

Exception example: Two sampled people are external contractors with commit rights to the main repository. Neither appears in the learning platform, because contractors are onboarded through procurement and not through HR. The population was incomplete, and some of the people writing production code never received the rules. This pattern is a frequent CC2 finding.

Common exceptions: Training completed months after the deadline. Acknowledgments collected for version 2 of a policy but never for version 3. No evidence that customers were told about a material change to the system described in the report.

CC3: Risk assessment

Summary: Risk assessment asks the organization to set clear objectives, work out what could stop it from meeting them, including fraud, and keep that picture current when the business, the technology or the vendors change. The controls tested in the other criteria are expected to trace back to the risks identified here.

What the criterion asks. CC3.1 asks for objectives defined clearly enough to identify the risks to them. CC3.2 asks for risks to be identified and analyzed. CC3.3 requires the organization to consider the potential for fraud. CC3.4 asks it to identify and assess changes that could significantly affect internal control.

How it is tested. At the organization level, the auditor inspects the annual risk assessment and checks that it was performed and approved within the period. At the SDLC level, CC3.2 and CC3.4 meet the threat model. The auditor typically takes the list of new features or significant changes from the period, samples it, and asks for the security risk assessment or threat model of each one. The attribute that matters most is the date. A threat model written after the feature shipped does not show that risk shaped the design.

Passing evidence example: The new payment export feature has a threat model in the repository dated two weeks before the first PoC commit. Three identified risks became backlog items with security acceptance criteria, and all three were closed before release. A fourth risk was accepted, and the acceptance is signed by the product owner and the security lead.

Exception example: Threat models exist for every sampled feature, but the git history shows four of them were created in the same week in August, right after the auditor’s evidence request. Auditors look at metadata. Artifacts created after the fact are a serious problem because they make the auditor question the reliability of the rest of your evidence.

Common exceptions: A risk register that has not changed since the previous audit. No fraud risk consideration at all. CC3.3 is easy to forget in engineering-led companies, and it covers insider scenarios such as a developer pushing a malicious change. Major architecture changes, like a move to a new cloud provider, without a documented risk assessment under CC3.4.

CC4: Monitoring activities

Summary: Monitoring is about confirming that controls keep working over time. The organization evaluates its controls through ongoing checks, separate assessments or both, and reports the deficiencies it finds to the people responsible for fixing them, who then track them to closure.

What the criterion asks. CC4.1 requires ongoing or separate evaluations, or both, to confirm that controls are present and functioning. CC4.2 requires deficiencies to be evaluated and communicated in time to the people responsible for corrective action.

An auditor’s note on the original mapping. In the earlier article I placed SAST, DAST and SCA scanning under CC4. Many auditors would map the scanning itself to CC7.1 (detection of vulnerabilities) and CC8.1 (testing of changes). CC4 is about monitoring the controls, not monitoring the system. In SDLC terms CC4 asks who checks that the scans, the reviews and the pipeline gates actually work, and what happens when they don’t. Both readings appear in practice, so agree on the mapping with your auditor before you build the control matrix.

How it is tested. The auditor looks for evidence that management evaluated its controls during the period. Internal audits, quarterly control self-assessments, documented reviews of compliance dashboards and penetration tests all count. For CC4.2 they sample the deficiencies identified during the period and trace each one to communication and remediation.

Passing evidence example: Every quarter the security team exports all merges to the main branch and compares them with the list of approved pull requests. In Q2 they found one merge where an administrator bypassed branch protection. A ticket was opened, the change was reviewed after the fact, the admin bypass was disabled, and the finding was reported to the CTO. The auditor can see the control, the deficiency and the correction in one trail.

Exception example: A scanning dashboard shows 140 open high-severity findings, some older than a year. Nobody reviewed it during the period. The scanner ran perfectly every night. The monitoring of its results never happened.

Common exceptions: Penetration test findings without remediation tracking. Quarterly reviews that took place in only two of four quarters. Deficiencies found internally but never escalated to management.

CC5: Control activities

Summary: Control activities are the concrete controls the organization picks to bring its risks down to an acceptable level. The criterion covers selecting those controls, putting general controls over technology in place, and rolling them out through written policies backed by procedures that people actually follow.

What the criterion asks. CC5.1 requires control activities that reduce risks to acceptable levels. CC5.2 requires general control activities over technology. CC5.3 requires that controls are deployed through policies and through procedures that put those policies into action.

How it is tested. Here the auditor checks that the secure coding standard, the review rules and the branch protection exist and match what the policy says. Configurations are checked across the whole period, not only on the day of fieldwork. A common request is the current branch protection settings together with the audit log of every change to those settings during the period.

Passing evidence example: The policy says every merge to main needs one approval from a code owner who is not the author, plus passing status checks for tests, SAST and secrets scanning. The repository settings match this, admin bypass is disabled, and the organization audit log shows no change to these rules between January and December.

Exception example: Branch protection matches the policy, but the audit log shows it was switched off for six hours on a Friday in May “to push a hotfix”. Five commits went in during that window without review. That is an exception under CC5 and, for the same commits, under CC8.

Common exceptions: A secure coding standard that still refers to a framework the company dropped two years ago. Repositories created during the period without branch protection, because new repositories are a classic gap. Policies written with “should” where the auditor expected “must”, which leaves nothing concrete to test.

CC6: Logical and physical access controls

Summary: This is the largest criterion and it covers who and what can get into the system. It deals with granting and removing access, least privilege and segregation of duties, physical access to facilities, protection at the system boundary, encryption of data in transit, secure disposal of assets, and protection against malicious software.

What the criterion asks. CC6 has eight criteria. The ones that matter most for the SDLC are CC6.1 (logical access security over protected information assets), CC6.2 (registration and authorization of users before credentials are issued), CC6.3 (role-based access, least privilege and segregation of duties), CC6.6 (protection against threats from outside the system boundary), CC6.7 (restricting how data is transmitted and moved, for example encryption in transit) and CC6.8 (preventing or detecting unauthorized or malicious software).

How it is tested. After CC8, CC6 produces the most populations. The auditor usually asks for the lists of new users, terminated users and role changes in the period, plus the user lists of the source code platform, the CI/CD system, the cloud console and the production databases. They sample joiners to confirm that access was approved before it was granted, and leavers to confirm that access was removed within the time the policy defines. They also inspect the periodic access reviews and check that the reviewer actually reviewed something. Removals or comments are good signs. A signature alone is weak evidence.

Passing evidence example: The policy requires deprovisioning within 24 hours of termination. For each of the 15 sampled leavers, the HR termination date, the SSO deactivation timestamp and the removal from the GitHub organization fall on the same day. The quarterly access review for the production AWS account shows the reviewer removed two engineers who had moved to another team.

Exception example: A developer left on 30 April. SSO was disabled the same day, but a personal access token for the CI system stayed valid and was used by an automated job on 12 May. Nobody noticed until the auditor compared token activity with the leavers list. Service accounts and long-lived tokens are the most common blind spot in CC6.

Common exceptions: PoC environments holding production data with broad access, never decommissioned. Shared admin accounts on build servers. Access reviews performed by the person who holds the access being reviewed. Secrets found in repository history without evidence that they were rotated.

CC7: System operations

Summary: System operations covers the security of systems while they run. The organization has to detect vulnerabilities and risky configuration changes, monitor for anomalies and attacks, evaluate security events to decide which ones are incidents, respond to those incidents, and recover from them.

What the criterion asks. CC7.1 requires detection and monitoring procedures for configuration changes that introduce vulnerabilities and for newly discovered vulnerabilities. CC7.2 requires monitoring of system components for anomalies that could indicate malicious acts, natural disasters or errors. CC7.3 requires evaluating security events to decide whether they are incidents. CC7.4 requires a defined incident response program. CC7.5 covers recovery from identified incidents.

How it is tested. For CC7.1 the auditor samples vulnerabilities identified during the period, often from SCA, container or infrastructure scans, and checks that each was fixed within the SLA in your vulnerability management policy. For CC7.2 and CC7.3 they sample alerts and check that each was triaged and documented. For CC7.4 and CC7.5 they sample the incidents of the period. If there were none, the auditor will usually ask for a tabletop exercise or another test that shows the process works.

Passing evidence example: The policy sets 7 days for critical and 30 days for high vulnerabilities. In a sample of 25 findings, every critical one was fixed within 2 to 6 days. One high finding took 41 days, but it has a risk exception with compensating controls that was approved before the SLA expired. The SIEM shows a login anomaly in August that was triaged within an hour and closed as a false positive with a written rationale.

Exception example: A new microservice went to production in March. Its logging was connected to the SIEM in July. For four months no events from that service were collected, so CC7.2 could not have operated for it. This is the “logging as a post-launch concern” gap from the original article, and it shows up when the auditor compares deployment dates with log onboarding dates.

Common exceptions: SLA breaches without an approved exception. Exceptions approved after the SLA had already expired. Alerts closed automatically by a rule without human review. An incident response plan that was never tested.

CC8: Change management

Summary: Change management has a single criterion, CC8.1. It requires that changes to infrastructure, data, software and procedures are authorized, designed or acquired, configured, documented, tested, approved and implemented in a controlled way. In an SDLC this is the criterion that touches every pull request and every release.

What the criterion asks. CC8.1 is a single criterion with a long list of points of focus. Changes to infrastructure, data, software and procedures must be authorized, designed, developed or acquired, configured, documented, tested, approved and implemented. The points of focus also address emergency changes, baseline configurations and patch management.

How it is tested. Most SDLC testing happens here. The auditor asks for a system-generated list of every production deployment in the period, usually exported from the CI/CD tool, and checks it for completeness. Some auditors reconcile it with the cloud provider’s own logs to find deployments that bypassed the pipeline. From that population they draw a sample, typically somewhere between 25 and 60 for a control that runs daily or more often, depending on the firm. Each sampled change is traced end to end: the ticket that authorized it, the pull request with an independent approval, the passing tests and scans, and the deployment record. Segregation of duties is checked on every sample. The author of a change must not be its only approver.

Passing evidence example: Deployment 2026-06-14-0932 traces to ticket PAY-1182, approved by the product owner. The code came from PR #4471, written by developer A and approved by developer B, who is a code owner. The CI run shows unit tests, SAST and SCA passing, and the deployment job was triggered by the pipeline service account, not by a person with console access.

Exception example: In two of 25 sampled deployments, the author pushed new commits after the pull request was approved. The “dismiss stale approvals” setting was off, so the merge went through on the old approval. The code that reached production was never reviewed in its final form. Auditors compare commit timestamps with approval timestamps for exactly this reason.

Common exceptions: Emergency changes without a documented approval after the fact. Infrastructure-as-code changes applied directly from a laptop. Database schema changes outside the pipeline. Configuration changes in SaaS tools, such as feature flags, that were missing from the change population entirely. System decommissioning at EOL without a change ticket.

CC9: Risk mitigation

Summary: Risk mitigation covers two areas. CC9.1 asks the organization to identify and prepare for risks of business disruption, for example through business continuity planning and insurance. CC9.2 asks it to assess and manage the risks that come from vendors and business partners.

What the criterion asks. CC9.1 asks for activities that mitigate risks from potential business disruptions, such as continuity planning and insurance. CC9.2 asks the organization to assess and manage risks associated with vendors and business partners.

An auditor’s note on the original mapping. In the earlier article I mapped the evaluation of open-source libraries to CC9. That reading can be defended, but many auditors limit CC9.2 to vendors and business partners with a contractual relationship, such as the cloud provider, the source code hosting platform or an outsourced development team. Dependency management is then tested under CC7.1 and CC8.1. Whichever mapping you choose, write it into the control matrix so the auditor tests the control where you expect it to be tested.

How it is tested. The auditor requests the vendor inventory and samples it, with attention to vendors added during the period. For each sampled vendor they look for a risk assessment before onboarding, a review of the vendor’s own SOC 2 report or an equivalent, and evidence that the complementary user entity controls (CUECs) listed in that report are implemented on your side. For CC9.1 they inspect the business continuity plan and evidence that it was tested during the period.

Passing evidence example: The SOC 2 Type 2 report of your code hosting provider was obtained in February. The review memo notes two exceptions in that report and explains why they do not affect you. It maps each CUEC, for example the customer’s responsibility to enforce MFA for its own users, to one of your controls, and confirms that MFA enforcement is switched on at organization level.

Exception example: An external development agency was hired in May and given write access to two repositories. There is no vendor assessment, no signed NDA in the contract repository, and the agency’s developers are missing from the access review. This single case touches CC9.2, CC6.2 and CC2.2.

Common exceptions: Vendor SOC 2 reports collected and never read. No bridge letter when the vendor’s report period does not cover yours. Vendors with production access that are missing from the inventory. A continuity plan that was never tested.

Preparing with the auditor’s view

Three habits make the largest difference when a Secure SDLC goes through a Type 2 audit.

The first is to let the work produce the evidence. A pipeline that refuses to deploy without an approved pull request and passing scans creates the CC5 and CC8 evidence on every run, and an automated control needs far fewer samples than a manual one.

The second is to test your own populations before the auditor does. Export every production deployment from the period, pick 25 at random and trace each one from ticket to deployment. Do the same with leavers and with vulnerabilities. The gaps you find this way are usually the gaps the auditor will find.

The third is to keep timestamps honest. Auditors compare the creation date of each artifact with the event it documents. A missing threat model is one exception. A threat model created after the fact can make the auditor doubt everything else you hand over.

The phase-by-phase mapping and the evidence checklist are in the original article, SOC 2 Type 2 mapping to Secure SDLC Requirements.

© Copyright 2026 Sorin Mustaca, All rights Reserved. Written For: Sorin Mustaca - Security & Technology

---

Want to work with me on this topic?
Check Endpoint Cybersecurity to see the consulting services we offer.