SOC 2, with an AI system inside the boundary.
SOC 2 was written for systems that process customer data, and a model is one. What changes is not the criteria — it is what counts as a change, what counts as evidence, and how you show a control operated across a period when the thing it controls keeps being retrained.
What is SOC 2 Type II?
An attestation report produced by an independent CPA firm against the AICPA's Trust Services Criteria. It is not a certification and not a pass mark — it is an opinion on whether the controls you described were suitably designed and, in a Type II, whether they operated effectively across a period.
- Type Attestation An opinion from an audit firm, not a certificate from a scheme.
- Type I Point in time Controls suitably designed as at a single date.
- Type II Period covered Controls operated effectively across an observation window.
- Always in scope Security The Common Criteria. The other four categories are elected.
Who needs SOC 2 Type II?
Nobody is legally required to hold one. It arrives through procurement, and once it does it is the fastest way through a vendor review.
- SaaS and platform vendors The default ask from enterprise buyers in North America, and increasingly the first question rather than the last.
- Anyone processing customer data with AI A model in the data path sits inside the system boundary. Leaving it out of scope is a decision the report description has to survive.
- Healthcare and fintech suppliers Where the buyer is regulated, the diligence flows down and Type II is usually the minimum accepted evidence.
- Teams already running ISO 27001 Substantial overlap in controls and evidence. The audit rhythm differs; the underlying work largely does not.
- Sub-processors Your customers' auditors reach you through their reports. Being ready is cheaper than being asked.
How iDharma supports SOC 2 Type II
We do not attest — that is the audit firm's role, and deliberately a separate one. We are the independent read before they arrive.
| Area | What the readiness review does |
|---|---|
| System boundary | What is inside the description, including the models, the inference path and the vendors behind them — the definition an auditor tests everything else against. |
| Control design | Each control read against the criterion it claims to meet, and against what actually happens rather than what the policy says. |
| Evidence generation | Whether the control produces a record on its own. Controls that only produce evidence when someone remembers to collect it fail Type II. |
| Change management | Model retraining, prompt changes and threshold moves treated as changes, with the approval trail that implies. |
| Access reviews | Who can reach training data, launch a fine-tune and change production inference, and whether the review has ever removed anyone. |
| Vendor management | Sub-service organisations identified, and the carve-out or inclusive method decision made deliberately rather than by default. |
| Monitoring | Logging, alerting and the record of what happened the last time an alert fired. |
We assess; we do not attest. The same firm cannot both prepare you and issue an independent opinion, and any provider offering both is selling you something the standard does not permit.
What the readiness review produces
Six areas, each delivering an artefact rather than an opinion.
System inventory and scope definition
The description everything hangs off
What is inside the boundary and what is deliberately outside, including models, training pipelines, inference endpoints and the providers behind them.
Risk assessment and treatment
CC3, done properly
A risk assessment that covers the AI estate, with treatment decisions recorded and owners attached rather than a register regenerated for the audit.
Control documentation and evidence
Criterion to control to record
Each control mapped to the criterion it satisfies and to the evidence it generates on its own — which is the difference between passing Type I and passing Type II.
Access management and user reviews
CC6, where samples land
Provisioning, deprovisioning and periodic review, including access to training data and model artefacts that sits outside the usual identity tooling.
Monitoring and incident tracking
CC7, and the part people skip
Alerting that reaches a person, incidents recorded with severity and owner, and the trail from detection through to closure.
Vendor risk management
CC9 and the sub-service question
Providers assessed and monitored, with the carve-out or inclusive decision made openly and reflected in the system description.
Complete Trust Services Criteria coverage
Security is common to every SOC 2. The other four are elected — and electing one you cannot evidence is worse than not electing it.
- CC Security The Common Criteria — always in scope
- Covered by the assessment
- A Availability Elected: uptime commitments and recovery
- Covered by the assessment
- PI Processing integrity Elected: complete, valid, accurate, timely
- Covered by the assessment
- C Confidentiality Elected: classification, handling, disposal
- Covered by the assessment
- P Privacy Elected: notice, choice, consent, rights
- Covered by the assessment
Continuous evidence
Controls assessed on whether they generate a record by themselves, because Type II tests a period rather than a day.
Audit-ready trail
Evidence indexed by criterion, in the shape an auditor samples from rather than a folder someone assembles later.
Model change control
Retraining, prompt and threshold changes inside the change process, which is the most common gap we find.
Multi-framework
Findings tagged to ISO 27001 and the CIS Controls, so one body of evidence answers more than one ask.
Five Trust Services Criteria
Security is the Common Criteria and is in every report. The other four are elected, and each one you elect is a set of commitments an auditor will test you against.
Security
The nine Common Criteria series
- CC1 control environment
- CC2 communication and information
- CC3 risk assessment
- CC4 monitoring activities
- CC5 control activities
- CC6 logical and physical access
- CC7 system operations
- CC8 change management
- CC9 risk mitigation
Availability
Only elect it if you measure it
- Capacity planning and monitoring
- Backup and recovery, tested
- Environmental and infrastructure controls
- Commitments actually measured against SLAs
- Incident recovery objectives evidenced
Processing integrity
The one AI complicates
- Processing complete, valid, accurate and timely
- Inputs validated before they reach the model
- Output quality monitored rather than assumed
- Errors detected, recorded and corrected
- Definitions of correct output agreed in advance
Confidentiality
Classification first
- Data classified and handled to its class
- Encryption in transit and at rest
- Disposal that actually happens
- Confidentiality commitments tracked
- Training corpora and prompt logs classified
Privacy
The heaviest to evidence
- Notice, choice and consent
- Collection limited to the stated purpose
- Access, correction and disposal routes
- Quality and monitoring of personal information
- Disclosure to third parties controlled
Choosing what to elect
Narrow and evidenced beats broad and thin
Elect what your customer commitments actually require and what you can evidence for the whole period. A Security-only Type II done well is worth more than a five-criteria report with exceptions across three of them.
SOC 2 Type I vs Type II
The difference is time, and time is the entire difficulty. Type I asks whether the control was designed; Type II asks whether it kept working while nobody was watching.
| Type I | Type II | |
|---|---|---|
| Question answered | Were controls suitably designed? | Did controls operate effectively? |
| Coverage | A single point in time | A period, commonly three to twelve months |
| Evidence | Design documentation and walkthroughs | Samples drawn across the whole period |
| Effort | Lower, and mostly documentation | Higher, and mostly operational discipline |
| Buyer acceptance | Increasingly treated as a staging post | The report enterprise buyers usually want |
| Common failure | Controls described but never operated | Controls operated but evidence not retained |
| Best used as | A first report while the period runs | The standing annual report |
Go straight to Type II if you have the time. A Type I that is never followed up reads as an abandoned effort, and buyers have learned to ask when the Type II is coming. The one good reason to issue a Type I is to have something in hand while the observation window runs.
Type II implementation roadmap
The observation period is the long pole regardless of how fast the rest goes, which is why the sequence matters more here than the calendar.
-
Phase 1
Scoping and gap assessment
Decide what the report covers
- Define the system and its boundary
- Elect the criteria categories honestly
- Inventory AI systems in the data path
- Identify sub-service organisations
- Gap-assess against the criteria
-
Phase 2
Control design and implementation
Write down what you will actually do
- Map controls to criteria
- Close the design gaps
- Extend change management over models
- Access review process stood up
- Agree the evidence each control produces
-
Phase 3
Evidence collection and monitoring
The observation period
- Run the controls for the full window
- Collect evidence continuously, not at the end
- Fix exceptions and record the fix
- Track incidents through to closure
- Readiness review before fieldwork
-
Phase 4
Audit and report
The firm's work, not ours
- Select an audit firm independently
- Support fieldwork and sampling
- Respond to exceptions
- Review the system description carefully
- Plan the next period before this one closes
Audit preparation essentials
What an auditor will ask for, in the order they will ask for it. Assembling this in advance is most of the difference between a smooth audit and an expensive one.
Documentation
Approved, dated, version-controlled
- System description, written and reviewed
- Policies covering each elected criterion
- Risk assessment with treatment decisions
- Org chart and role definitions
- Vendor list with the sub-service decision
- Complementary user entity controls stated
Evidence collection
Across the period, not at the end
- Access review records with outcomes
- Change tickets including model changes
- Onboarding and offboarding records
- Monitoring alerts and what followed them
- Incident records traced to closure
- Backup and restoration test results
Testing readiness
Sampling is where reports go wrong
- Populations complete and reconcilable
- Timestamps that survive scrutiny
- Named owners who can explain each control
- Exceptions self-identified before the auditor finds them
- Remediation evidence for anything fixed mid-period
- A single index by criterion
Sampling is where readiness is really tested. An auditor asks for a population, then samples it. If the population cannot be produced completely — every change, every access grant, every incident in the window — the control cannot be tested, however well it was designed.
How SOC 2 compares to other standards
Different instruments answering different questions. Most organisations end up holding more than one, and the overlap in underlying evidence is large.
| SOC 2 | ISO 27001 | NIST CSF | CIS Controls | |
|---|---|---|---|---|
| Output | Auditor report and opinion | Certificate | No artefact | No artefact |
| Issued by | A CPA firm | Accredited certification body | Self-assessed | Self-assessed |
| Governs | Controls against criteria | A management system | Outcomes | Specific safeguards |
| Scoping device | System boundary | Statement of Applicability | Tiers and Profiles | Implementation Groups |
| Geography | North American default | International default | US, often by contract | Universal, informal |
| Renewal | Annual report period | Surveillance and recertification | Continuous | Continuous |
| Best at | Answering a customer | Proving it is managed | Deciding what matters | Deciding what to build first |
Each has its own page: ISO 27001, NIST CSF and CIS Controls. Running SOC 2 and ISO 27001 together is materially cheaper than running them apart, because most of the evidence serves both.
Consequences of not having one
SOC 2 is not law, so the consequences are not legal. They are commercial, they are immediate, and they compound — which for most vendors makes them sharper than a penalty would be.
Deals that stall
Enterprise procurement increasingly treats a Type II as a gate rather than a preference. Without one the deal does not get rejected — it sits, which is worse for forecasting and worse for the team.
Questionnaires instead
What replaces the report is a bespoke security questionnaire per customer, answered by your engineers. The cost never appears on a budget line, and it never stops.
A competitor who has one
When two vendors are otherwise close, the one with a current Type II is the lower-risk choice for the buyer's security team — and that team is often the one with the veto.
SOC 2-aligned policy repository
Ready-to-use templates organised by criterion, with mapping across to ISO 27001 so one set of documents serves both audits instead of two overlapping sets.
Security (Common Criteria)
- Information Security Policy
- Risk Assessment Procedure
- Access Control Policy
- Change Management Procedure
- Incident Response Plan
- Vendor Management Policy
+ 5 more policies
Availability & processing
- Business Continuity Plan
- Backup & Recovery Standard
- Capacity Management Standard
- Processing Integrity Controls
- Model Output Monitoring Standard
- Error Handling Procedure
+ 3 more policies
Confidentiality & privacy
- Data Classification Policy
- Encryption Standard
- Data Retention & Disposal
- Privacy Notice & Consent Standard
- Data Subject Request Procedure
- Prompt & Log Handling Standard
+ 4 more policies
Frequently asked questions
What comes up in every SOC 2 scoping call.
What is the difference between Type I and Type II?
Type I tests whether controls were suitably designed at a point in time. Type II tests whether they operated effectively across a period, commonly three to twelve months. The difference is time, and time is the entire difficulty — Type II is mostly operational discipline rather than documentation.
Is SOC 2 a certification?
No. It is an attestation — an opinion from an independent CPA firm on controls you described. There is no pass mark and no certificate. What a customer receives is a report containing the opinion, your system description and, in a Type II, the tests performed and any exceptions found.
Which Trust Services Criteria should we elect?
Security always; it is the Common Criteria and every report includes it. Beyond that, elect what your customer commitments actually require and what you can evidence for the whole period. A Security-only Type II done well is worth more than a five-criteria report with exceptions scattered across it.
How long does the observation period need to be?
Commonly three to twelve months, and firms differ on what they will accept for a first report. Three months is the usual starting point; twelve is where most programmes settle once the annual rhythm establishes itself.
Does our model have to be in the boundary?
If it processes customer data or shapes a service commitment, keeping it out is a decision that has to be defensible and visible in the system description. Auditors and customers both read the boundary first, and a conspicuous omission gets noticed.
How do we handle a third-party model provider?
As a sub-service organisation. You choose the carve-out method, which excludes their controls and says so, or the inclusive method, which brings them in. Either is legitimate; what is not is leaving it ambiguous in the description.
Does retraining break our change management control?
It breaks it if the control was written for code and never extended. A model version change alters system behaviour, so it needs the same approval, testing and record trail. This is the most common gap we find in AI-heavy environments.
What does processing integrity mean for a probabilistic system?
It means monitoring output quality rather than asserting correctness. You agree in advance what acceptable output looks like, measure against it across the period, and record what happened when it drifted. Electing this criterion without that machinery is how exceptions appear.
How does SOC 2 relate to ISO 27001?
They overlap heavily in substance and differ in form: ISO certifies a management system against a standard, SOC 2 attests to controls against criteria. Most of the underlying evidence serves both, which is why running them together costs far less than running them apart.
What is a bridge letter?
A statement from management covering the gap between the end of your report period and a customer's point of enquiry, confirming no material changes. It is convention rather than standard, and it is not a substitute for a current report.
Can you be our auditor?
No, and that is deliberate. We do the independent readiness review; a CPA firm issues the opinion. Keeping those separate is what makes both worth having, and a provider offering both is selling something the standard does not permit.
What derails audits most often?
Populations. An auditor asks for every change, every access grant or every incident in the window, then samples it. If the population cannot be produced completely, the control cannot be tested however well it was designed — and that is a readiness failure rather than a control failure.
Ready to achieve SOC 2 Type II?
Boundary, controls, evidence and the change management that covers your models — reviewed before the audit firm arrives.
This page is guidance on how we scope an assessment, not legal advice. We review; the attestation is issued by an independent CPA firm.