# The Clean Opinion — full text
> Independently operated publisher of SOC 2, SOX 404 and cybersecurity readiness guidance, written with the audit team at Alpha Secure LLP, a licensed CPA firm. Five free tools that run in the browser, explainers that cite primary sources, a free access-control policy check, and a paid SOC 2 policy review. The tools are practitioner judgement, not standards: no weight, threshold or week count in any of them is published by the AICPA, the SEC, the PCAOB or NIST, and each page says so where it matters.
This file is the published text of https://thecleanopinion.com in full: 6 articles and 6 method sections. It is generated at build time from the same source the pages render from, so it cannot fall behind them. Unpublished drafts are excluded. Each entry carries its canonical URL; cite that rather than this file.
Attribution: The Clean Opinion (thecleanopinion.com)
These tools give planning estimates from the answers supplied. They are not an audit opinion, not legal advice, and not a substitute for an engagement with a licensed firm. Audits and attestations are performed by Alpha Secure LLP, a licensed CPA firm. Every weight, threshold and interval is practitioner judgement published at https://thecleanopinion.com/how-scoring-works/, not a figure set by the AICPA, the SEC, the PCAOB or NIST.
---
## Articles
### AI agents and SOC 2: the audit trail your auditor is about to ask for
URL: https://thecleanopinion.com/articles/ai-agents-soc-2-audit-trail/
Category: SOC 2
Published: 2026-08-26. Updated: 2026-09-10.
Author: The Clean Opinion
Shadow AI feeding customer data into unvetted vendors is now a recurring SOC 2 finding. Here is what auditors ask about model use, prompt logs, and third-party LLMs.
A year ago, AI came up in a SOC 2 engagement as a curiosity. In 2026 it comes up in the opening meeting, and it comes up as a scoping question: *which systems, which vendors, and which data.* The most common question compliance teams are asking each other right now is “how do we prove what an AI agent did?” That is exactly the right question, because it is the one the auditor is going to ask.
## Why this became a finding category
Two things happened at once. Engineering teams started wiring language models and agents into products and internal tools — customer support, code review, document processing, data pipelines. And employees started pasting customer data into whatever assistant was open in another tab. Both create the same control problem: **data leaving your environment to a subprocessor that was never assessed, with no record of what was sent or what came back.**
Under SOC 2, that touches confidentiality, privacy (if in scope), vendor management, logical access, and change management all at once. It isn’t a new criterion. It is an old set of criteria applied to a new class of system.
## What auditors are asking now
In recent engagements the questions cluster into four groups.
**1. Inventory and classification.** Which AI models and agents are in use — vendor-hosted and self-hosted, in the product and internally? For each: what data does it receive, who owns it, and what business process depends on it? If the answer is a shrug, that is the finding. Shadow AI is, at root, an incomplete asset inventory.
**2. Vendor risk for every third-party model.** Each hosted LLM provider is a subprocessor. Auditors expect the same due diligence you would apply to any vendor touching customer data: their SOC 2 report, data-retention and training-use terms, region, breach notification, and whether the contract actually prohibits training on your data. “It’s a big company” is not a vendor assessment.
**3. Logging and traceability.** For agents that take actions — sending an email, changing a record, running a query — auditors want to see who or what initiated the action, what input it acted on, what it did, and when. Prompt and inference logs, with sensitive fields redacted, retained for a defined period, protected from alteration. If an agent can modify data that feeds a control, its actions are in scope the same way a user’s are.
**4. Change management and model lineage.** Which model version is in production, who approved the change, and was it tested? A model swap is a production change. A prompt template that governs an agent’s behavior is configuration. Both need the same trail as code.
## The minimum that passes
You do not need an AI governance program with a steering committee to get through a SOC 2 audit. You need the controls you already have, extended to cover the new systems.
| Control you already have | Extension for AI |
|---|---|
| Asset inventory | Add every model, agent, and AI vendor, with data classification and an owner |
| Vendor management | Assess each LLM provider as a subprocessor; retain the SOC 2 report and the data-use terms |
| Acceptable-use policy | State plainly what data may and may not go into external AI tools; train on it; make a sanctioned tool available |
| Logical access | Agents get their own identities and least-privilege credentials — no shared API keys, no standing admin rights |
| Logging and monitoring | Log agent actions and model calls; redact; retain; restrict who can alter logs |
| Change management | Model versions and prompt templates go through the same approval and testing trail as code |
| Incident response | Add “data sent to an unapproved AI tool” as an incident category with a defined response |
## The shadow-AI problem specifically
The most common finding is not a sophisticated one. It is a support rep pasting a customer’s ticket — name, account details, sometimes payment information — into a consumer chatbot to draft a reply. No malice, no policy, no log.
Three things fix it, in order of effectiveness:
1. **Give people a sanctioned tool.** A contracted enterprise assistant with data-use terms you have reviewed. Prohibition without an alternative fails every time.
2. **Say what the rule is, in writing, and train on it.** One paragraph in the acceptable-use policy and ten minutes in security training.
3. **Watch the network.** Block or flag unapproved AI endpoints from managed devices. Not perfect, but it turns an unknowable problem into a monitored one.
## What to tell your auditor before they ask
Put a one-page AI inventory in the audit package: the models and agents in use, the vendors, the data each touches, the owner, and which of the controls above covers it. Auditors do not expect perfection here; the field is moving quickly. They expect to see that you know what you have and that it sits inside the control environment rather than outside it. That is the difference between a conversation and a finding.
Sources cited:
- TSP Section 100, 2017 Trust Services Criteria (With Revised Points of Focus — 2022) — AICPA Assurance Services Executive Committee: https://assets.ctfassets.net/rb9cdnjh59cm/5jT1narHNQNzt4JGlkd1gr/248661d08e42531329d147782a6f8854/Trust-services-criteria.pdf
- System and Organization Controls: SOC Suite of Services — AICPA & CIMA: https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
Questions and answers:
Q: Is there a SOC 2 criterion specifically about AI?
A: No. There is no AI-specific trust services criterion. What applies is the existing set — vendor management, logical access, change management, confidentiality and, where in scope, privacy — read against a new class of system. That is why the fix is extending controls you already have rather than building an AI governance programme.
Q: Is a hosted language model a subprocessor?
A: If it receives customer data, treat it as one. That means the same diligence you would apply to any vendor touching customer data: their report, the data-retention and training-use terms, the region, breach notification, and whether the contract actually prohibits training on your data.
Q: Do we need to log every prompt?
A: You need to be able to show who or what initiated an action, what it acted on, what it did, and when — for agents that take actions rather than just produce text. Prompt and inference logs with sensitive fields redacted, retained for a defined period and protected from alteration, are the usual way to do that.
Q: Is a model version change a change-management event?
A: Yes, in the sense that matters to an auditor. A model swap is a production change and a prompt template that governs an agent's behaviour is configuration. Both want the same approval and testing trail as code, for the same reason: something that changes system behaviour changed, and someone should have approved it.
---
### ITGC scoping for SOX: the four controls your auditor tests first
URL: https://thecleanopinion.com/articles/itgc-scoping-sox-four-controls-auditors-test-first/
Category: SOX 404
Published: 2026-08-26.
Author: The Clean Opinion
Logical access, privileged access, deprovisioning, and change management. Get these four right and most of the ITGC conversation goes away.
The most common question from a controller who has just inherited a SOX program is some version of “how do I scope ITGCs so the auditor accepts it?” Usually it comes with a list of every system in the company and a look of dread. The list is the wrong place to start.
IT general controls exist for one reason in a SOX program: to support the automated controls and system-generated reports that your financial controls depend on. If a control depends on a system, the system has to be reliable. That is the whole test. Scope follows from it.
## Start from the financial statements, not the system inventory
Work backwards:
1. **Significant accounts and disclosures** → the transaction cycles that feed them (revenue, purchasing, payroll, close, treasury).
2. **The key controls in each cycle** → which of them are automated, or rely on a system-generated report, calculation, or interface.
3. **The systems behind those controls** → the application, its database, the operating system and infrastructure it runs on, and the interfaces between them.
That last list is your ITGC scope. Everything else — the marketing CRM, the HR survey tool, the dev sandbox — is out of scope unless it feeds a financial control. Write down *why* each excluded system is excluded. Auditors accept a documented exclusion; they don’t accept a silent one.
## The four control areas that decide the outcome
Across first-year and remediation engagements, four areas produce almost all of the ITGC deficiencies. They are not the most technical controls. They are the ones where the evidence is either there or it isn’t.
### 1. Logical access — who can get in, and who approved it
The auditor will pull a sample of new users during the period and ask for the approved request for each one. Then they will pull the full user list for each in-scope system and ask who reviewed it and when.
What passes: role-based access approved by a business owner before it is granted; a periodic (usually quarterly) review of users and their permissions, by someone who understands what the permissions mean, with the export, the sign-off, and the removals retained.
What fails: access granted “by IT” with no request on file; reviews that say “looks fine” with no population attached; a review of the application that ignores the database and the cloud console underneath it.
### 2. Privileged access and segregation of duties
This is the area that produces the most disagreement, and for good reason. Administrator accounts, developer access to production, and service accounts are where management override and undetected change live.
What passes: a named list of privileged users, each with a business reason; privileged activity logged and reviewed; developers without standing production access, or with monitored break-glass access that is reviewed after use; segregation conflicts identified and either removed or covered by a documented compensating control that actually operates at a precision that would catch a material error.
What fails: “everyone in IT is an admin”; a compensating control that consists of a manager glancing at a report with no threshold or follow-up.
### 3. Deprovisioning — the terminated user who still has access
The simplest test in the audit: take the HR termination list, match it against active users in each in-scope system, and look for anyone who should be gone. One match is an exception. Several is a design deficiency.
What passes: termination triggers a ticket; access is removed within a defined window (same day for privileged users, a few days for everyone else); the ticket records the removal date; a periodic reconciliation of HR to active users catches anything that slipped.
What fails: removal depends on a manager remembering to email IT. Contractors and vendor accounts that never appear on the HR list at all.
### 4. Change management and information used in controls
Two related questions. First: can a change reach production without being authorized, tested, and approved by someone other than the developer? The auditor samples changes and asks for the trail on each.
Second — and increasingly the bigger finding — **information used in controls (IUC)**. If a control relies on a report (an aging, a journal-entry listing, an exception report), management has to show that the report is complete and accurate: where it comes from, what parameters were used, and that it hasn’t been altered. “We pull it from the system” is not evidence. The retained report, the query or parameters, and a tie-out to source is.
What passes: ticketed changes with test evidence and approval; branch protection or equivalent enforced by tooling; a report inventory naming each IUC, its source, and how completeness and accuracy are validated; the reports themselves retained for the period.
What fails: infrastructure and configuration changes that bypass the change process; reports validated once at implementation and never again; spreadsheets that feed a control with no version control or access restriction.
## Third-party systems: SOC 1 reports are part of scope, not a substitute for it
If a hosted payroll, billing, or ERP provider runs part of a financial process, you need their SOC 1 Type 2 report, and you need to actually read it: does the period cover yours, what are the complementary user-entity controls, and are you performing them? Exceptions in the vendor’s report are your problem to evaluate. A bridge letter covers the gap between their period-end and yours.
## Defending the scope to the auditor
Bring three documents to the planning meeting:
| Document | What it shows |
|---|---|
| Application inventory | Every system, the financial controls it supports, and the components in scope (app, DB, OS, interfaces) — or the reason it is excluded |
| Risk-control matrix with ITGC linkage | Which automated controls and IUC depend on which systems |
| ITGC control listing | Owner, frequency, evidence, and testing approach for each control in the four areas above |
With those three, the scoping conversation is short. Without them, the auditor scopes it for you, which is always broader and always more expensive.
Sources cited:
- Statement on Auditing Standards No. 145 (AU-C section 315) — Appendix F, Considerations for Understanding General IT Controls — AICPA Auditing Standards Board: https://assets.ctfassets.net/rb9cdnjh59cm/36dIstmjNFLm48jrBBHD92/f9bdb47a639348a3ebb08328f60e0496/sas-145.pdf
- AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements — Public Company Accounting Oversight Board: https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201
- Internal Control — Integrated Framework: Executive Summary (2013) — see Principle 11 on general controls over technology — Committee of Sponsoring Organizations of the Treadway Commission: https://www.coso.org/_files/ugd/3059fc_1df7d5dd38074006bce8fdf621a942cf.pdf
- 17 CFR 229.308 (Item 308) — Internal control over financial reporting — Electronic Code of Federal Regulations: https://www.ecfr.gov/current/title-17/part-229/section-229.308
Questions and answers:
Q: Is 'IT general control' a defined term, or industry jargon?
A: It is defined. The AICPA's SAS No. 145, in force for audits of periods ending on or after 15 December 2023, defines general IT controls as controls over the entity's IT processes that support the continued proper operation of the IT environment. Its Appendix F lists examples by process, naming provisioning, deprovisioning, privileged access and user-access reviews.
Q: What are the classic ITGC domains?
A: Access to programs and data, program changes, and computer operations. The PCAOB's AS 2201 uses that grouping when it discusses benchmarking automated controls — general controls over 'program changes, access to programs, and computer operations'. Most scoping documents follow the same three headings.
Q: Do we have to scope every system the company uses?
A: No, and starting from the system list is the mistake. Scope follows the financial statements: identify the significant accounts and disclosures, then the controls that address them, then the systems those controls depend on. Anything that does not support a control relevant to financial reporting is out, and you should write down why.
Q: Does a SOC 1 report from a hosted provider cover our ITGCs?
A: Only partly. It covers the provider's controls for the period its report covers, which is rarely identical to yours — hence bridge letters for the gap. It also lists complementary user entity controls that you are expected to perform, and those are yours to operate and evidence.
---
### A breach is a financial reporting problem now, not just a security one
URL: https://thecleanopinion.com/articles/breach-is-a-financial-reporting-problem/
Category: Cyber
Published: 2026-08-24. Updated: 2026-09-10.
Author: The Clean Opinion
The disclosure clock runs from management's materiality determination, not from the intrusion. That makes the CFO's judgement — and the evidence behind it — part of the incident response.
For most of the last two decades, a breach was the CISO's problem and the CFO found out at the board meeting. That division is over, and the companies still running on it are the ones that get hurt twice — once by the attacker, and once by the disclosure.
## 1. The clock runs from your judgement, not from the intrusion
Public companies must disclose a material cybersecurity incident on Form 8-K under Item 1.05. General Instruction B.1 to the form sets the deadline: a report under Item 1.05 "is to be filed within four business days after the registrant determines that it has experienced a material cybersecurity incident."
Read that again, because most summaries get it wrong. The clock does not start when the attacker gets in, or when you find them. It starts when management **determines** the incident is material.
That is not an invitation to take your time. Instruction 1 to Item 1.05 is explicit: "A registrant's materiality determination regarding a cybersecurity incident must be made without unreasonable delay after discovery of the incident." The adopting release puts it plainly — the determination "need not be rushed prematurely" but "cannot be unreasonably delayed in an effort to avoid timely disclosure." It goes on to give examples of what unreasonable looks like: deferring the committee meeting past the time it normally takes to convene, or amending incident-response procedures so that the deadline moves.
The word *generally* belongs in any summary of the four days, because there are two codified delay routes: a national-security deferral certified by the Attorney General, and a short deferral for registrants subject to the FCC's telecom breach-notification rule.
One piece of stale advice worth retiring: smaller reporting companies did get an extra 180 days when the rule arrived, and **that deferral expired on 15 June 2024**. Every category of registrant is in scope now.
**What this means for you:** the materiality determination is a *financial-reporting* judgement. It belongs to the disclosure committee and the CFO, informed by the security team — not the other way around. If your incident-response plan has no defined path for it, with named participants and an agreed information set, you do not have a plan that works for a public company. The release's own comfort is that "adhering to normal internal practices and disclosure controls and procedures will suffice to demonstrate good faith compliance" — which only helps if those practices exist in writing before the incident.
## What enforcement has actually looked like
Worth being precise here, because this area has moved and a lot of published commentary has not kept up.
In **October 2024** the SEC charged four companies — Unisys, Avaya, Check Point and Mimecast — over disclosures it said understated the impact of intrusions connected to the SolarWinds Orion compromise, settling for roughly $7 million in total. The charges concerned disclosures that were **incomplete or framed to understate impact**, not disclosures that were filed late. We have not found an enforcement action premised on missing the four-business-day clock itself.
Two changes since then matter:
- The **Crypto Assets and Cyber Unit**, which brought that generation of cases, was **replaced in February 2025** by the Cyber and Emerging Technologies Unit, a smaller group framed around fraud and retail-investor protection in emerging technologies rather than public-company disclosure policing.
- In **R.R. Donnelley** (June 2024) the SEC advanced a theory that weak cybersecurity controls violated the internal *accounting* controls provision — a charge two commissioners publicly dissented from. A federal court **rejected that theory** in the SolarWinds case in July 2024, and the case was dismissed with prejudice in **November 2025**.
None of that reduces the disclosure obligation, which is a rule and remains in force. It does mean you should discount anyone describing an aggressive and expanding cyber-enforcement posture; the record over the past two years points the other way.
## 2. Ransomware: payment rates falling, disruption rising
Two published figures are worth having, both from free sources you can check yourself.
On volume, Comparitech logged **4,217 ransomware attacks in the first half of 2026, against 3,706 in the first half of 2025** — an increase of roughly 14%, on a leak-site counting methodology.
On payment, Coveware by Veeam reported that in the second quarter of 2026 "the percentage of clients that ultimately choose to pay sank to a new record low," with the data-exfiltration-only payment rate down to **15%**. That is the share of *Coveware's own incident-response clients*, not of all victims globally — a distinction worth keeping, because no one measures the global population.
Fewer payments is good news, and it changes the shape of the risk rather than removing it. When payment is not on the table, the damage is **operational and financial**: days or weeks of disruption, restoration cost, lost revenue, and — for a public company — the question of whether the books can be closed on time.
Two patterns are worth naming, with the sources that actually measure them:
- **Third parties are now involved in about half of breaches.** Verizon's 2026 Data Breach Investigations Report puts third-party involvement at **48% of all breaches**, up 60% year over year, and reports that vulnerability exploitation has passed stolen credentials as the leading entry point at **31%** — the first time in nineteen editions. Your perimeter is your vendors' perimeter.
- **Attacker timelines are compressing.** The same report describes AI shrinking the window from vulnerability disclosure to exploitation "from months to mere hours," and CrowdStrike reports adversaries moving from initial access to lateral movement in minutes. Detection windows that were adequate two years ago are not adequate now.
**What this means for you:** the backup and recovery question is not theoretical. Can you restore the general ledger, the billing system, and the identity provider from backups the attacker could not reach, within a time that lets you close the quarter? If you have not tested a full restore in the last year, the honest answer is "we don't know."
## 3. When a breach touches the books
Here is the part that catches CFOs off guard, and here is where we are going to be careful to separate what the rules say from what we think.
**What we think.** Where an incident impairs a system relevant to financial reporting — the ERP is encrypted, the billing platform is offline, journal-entry approvals are bypassed during recovery — the right question is not only whether it was a security event. It is whether the IT general controls over that system, particularly access and change management, were operating effectively through the period, and whether any deficiency rises to a significant deficiency or material weakness under the ordinary severity framework. That is a professional judgement we hold, and it follows from an uncontroversial premise: ITGCs are part of internal control over financial reporting, so a breach that compromises them can surface a control deficiency.
**What we are not saying.** We are not saying regulators treat a breach as an ICFR deficiency as a matter of course. The nearest regulatory theory — that inadequate cybersecurity controls violate the internal accounting controls provision — was advanced against R.R. Donnelley, dissented from by two commissioners, and rejected by a federal court in SolarWinds. Anyone telling you the SEC now treats breaches as control failures is describing a theory that lost.
The practical consequences of the judgement, though, are real:
| If the incident… | Then… |
|---|---|
| Impairs a system behind a key control | The control did not operate for that period; the deficiency has to be evaluated for severity |
| Forces manual workarounds during recovery | Those workarounds are compensating controls and need evidence, precision, and review |
| Alters or destroys financial data or logs | Completeness and accuracy of the affected period has to be re-established |
| Is material | It is disclosed on Form 8-K *and* considered in the quarterly Section 302 certification and the annual 404(a) assessment |
The CISO cannot make those evaluations alone. The controller cannot make them without the CISO. This is why the wall is gone.
## What the CFO owns, concretely
1. **The materiality determination process.** Written, rehearsed, with named participants and a defined information set. This is a disclosure control.
2. **The link between the IT asset inventory and the financial control matrix.** Which systems support which key controls — so that when the security team says "system X is down," finance immediately knows which controls are affected.
3. **Recovery objectives for financial systems.** Recovery time and recovery point objectives for the ledger, sub-ledgers, billing, payroll, and identity — set by finance, delivered by IT, tested at least annually.
4. **Deficiency evaluation after an incident.** A standing agenda item in the post-incident review: which controls did not operate, for how long, what compensated, and what goes to the audit committee.
5. **Board and audit-committee reporting that ties security to financial risk.** Not a slide of vulnerability counts — a statement of which financial processes are exposed, what the recovery posture is, and what has changed since last quarter.
## The uncomfortable summary
The disclosure obligation turns on a judgement that belongs to finance. The recovery question turns on whether the systems finance depends on can be brought back in time to close. And the control question — the one nobody is required to ask you, and every auditor will — turns on whether the controls over those systems were working while the incident ran.
Treating cybersecurity as part of the financial control environment, evidenced the same way and reported to the same committee, is more work for the CFO. It is also the only structure in which a breach is a bad week rather than a restatement.
Sources cited:
- Form 8-K — Item 1.05, Material Cybersecurity Incidents (see also General Instruction B.1) — U.S. Securities and Exchange Commission: https://www.sec.gov/files/form8-k.pdf
- Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure (Release Nos. 33-11216; 34-97989), 88 FR 51896 — Federal Register: https://www.federalregister.gov/documents/2023/08/04/2023-16194/cybersecurity-risk-management-strategy-governance-and-incident-disclosure
- Fact Sheet: Public Company Cybersecurity Disclosures; Final Rules — U.S. Securities and Exchange Commission: https://www.sec.gov/files/33-11216-fact-sheet.pdf
- SEC Charges Four Companies With Misleading Cyber Disclosures (Press Release 2024-174) — U.S. Securities and Exchange Commission: https://www.sec.gov/newsroom/press-releases/2024-174
- SEC Announces Cyber and Emerging Technologies Unit to Protect Retail Investors (Press Release 2025-42) — U.S. Securities and Exchange Commission: https://www.sec.gov/newsroom/press-releases/2025-42
- SEC v. SolarWinds Corp. and Timothy G. Brown — Litigation Release No. 26423 (dismissal with prejudice, 20 November 2025) — U.S. Securities and Exchange Commission: https://www.sec.gov/enforcement-litigation/litigation-releases/lr-26423
- In the Matter of R.R. Donnelley & Sons Co., Exchange Act Release No. 100365 (18 June 2024) — U.S. Securities and Exchange Commission: https://www.sec.gov/files/litigation/admin/2024/34-100365.pdf
- Ransomware Payment Trends Q2 2026 — Coveware by Veeam — Veeam: https://www.veeam.com/blog/cyber-extortion-payment-trends-q2-2026.html
- Ransomware Roundup: H1 2026 stats on attacks, ransoms, and active gangs — Comparitech: https://www.comparitech.com/news/ransomware-roundup-h1-2026-stats-on-attacks-ransoms-and-active-gangs/
- Vulnerability exploitation top breach entry point, 2026 industry-wide DBIR finds — Verizon: https://www.verizon.com/about/news/breach-industry-wide-dbir-finds
Questions and answers:
Q: When does the four-business-day clock actually start?
A: When management determines the incident is material — not when the intrusion happened, and not when it was discovered. Instruction 1 to Item 1.05 requires that determination to be made without unreasonable delay after discovery, so the clock cannot be stopped by simply not deciding.
Q: Does every public company have to comply, or do smaller companies get longer?
A: Every category of registrant is now in scope. Smaller reporting companies had an additional 180 days when the rule came in, and that deferral expired on 15 June 2024. Any advice suggesting smaller companies still have extra time is out of date.
Q: Is a breach automatically a material weakness in internal control over financial reporting?
A: No, and nobody should say that it is. The question is whether the IT general controls over the affected system — access and change management in particular — were operating effectively, and whether any deficiency rises to a significant deficiency or material weakness under the usual severity framework. That is a judgement, made case by case.
Q: Has the SEC actually brought enforcement actions over cyber disclosure?
A: Yes, though not for missing the filing deadline. In October 2024 the SEC charged four companies over disclosures it said understated the impact of the SolarWinds Orion compromise. Its broader theory — that weak cybersecurity controls violate the internal accounting controls provision — was rejected by a federal court in the SolarWinds case, which was dismissed with prejudice in November 2025.
Q: Who should own the materiality determination?
A: The disclosure committee and the CFO, informed by the security team. It is a financial-reporting judgement about impact, not a technical judgement about severity, and the SEC's adopting release treats adherence to normal internal practices and disclosure controls as evidence of good-faith compliance.
---
### SOC 2 Type 1 vs Type 2: which one actually unblocks the deal?
URL: https://thecleanopinion.com/articles/soc-2-type-1-vs-type-2/
Category: SOC 2
Published: 2026-08-22. Updated: 2026-09-10.
Author: The Clean Opinion
Type 1 gets you into the conversation in weeks. Type 2 closes the larger accounts later. Most companies pick wrong because they start the week procurement asks.
A CTO recently asked whether they could "just buy the SOC 2 badge." The honest answer is that there are two different badges, they prove different things, and the one you pick determines whether your next enterprise deal closes this quarter or next year.
## What each report proves
A **Type 1** examination looks at whether your system description is accurate and your controls are suitably designed **as of a point in time**. A **Type 2** examination covers the same ground and adds one more subject matter: whether those controls **operated effectively throughout a period of time**. A Type 2 report also includes the auditor's detailed description of the tests performed and their results — which is why it is longer, and why reviewers read it differently.
That difference sounds academic until you are on the receiving end of a vendor review. A Type 1 says "we built the thing." A Type 2 says "the thing has been running, and someone checked, and here is what they found."
Both are attestation examinations performed under the AICPA's attestation standards — AT-C section 105 and AT-C section 205 — against the trust services criteria in TSP section 100.
> **A precision worth having.** The familiar phrasing "as of a specified date" versus "throughout the specified period" comes from AT-C section 320, which is the **SOC 1** standard. Vendor blogs copy it constantly as though it were the SOC 2 definition. The SOC 2 wording is "as of a point in time" and "throughout the period of time." If you are being asked to sound precise in front of an auditor, that is the distinction to get right.
## What procurement actually accepts
In practice, a Type 1 is enough to unstick many mid-market deals where the buyer's security team needs something to attach to the risk file. Larger enterprises, banks, and anyone running a formal third-party risk program will eventually ask for the Type 2 — but "eventually" often means at renewal, not at signature.
| | Type 1 | Type 2 |
|---|---|---|
| What it proves | Controls are suitably designed | Controls also operated over a period |
| Point of reference | A point in time | A period of time |
| Contains test results | No | Yes — the auditor's tests and their results |
| Time to report | Weeks once ready | Observation window, then fieldwork |
| Who tends to accept it | Many mid-market buyers | Enterprise, financial services, regulated |
| Typical use | Unblock the first deal | Keep and grow the account |
We should be honest that the right-hand column of "who accepts it" is a description of what we see, not a rule. Whether a Type 1 clears a given buyer's bar is set by that buyer's third-party risk policy. The fastest way to find out is to ask them, in writing, before you scope anything.
## Which one do you need?
A short decision path that gets most companies to the right answer:
1. **Has a specific customer asked, with a date?** If not, the question is premature — build the controls and pick a window on your own schedule. If yes, ask them exactly which report satisfies their policy, and whether a Type 1 with a committed Type 2 date is acceptable. A surprising number of policies say yes.
2. **Have your controls been operating, with evidence retained, for at least a few months?** If yes, a Type 1 is probably wasted money and you should scope a Type 2 window that ends near the buyer's date. If no, a Type 1 is the only thing that can exist in the near term.
3. **Is the deadline inside the shortest observation window you could credibly run?** If it is, no Type 2 can exist by then, and the conversation you need to have is about resetting the date — not about finding a faster auditor.
4. **Do you know which trust services categories are in scope?** Security is addressed in most engagements. Availability, processing integrity, confidentiality and privacy each add criteria, effort, and cost. A buyer asking for "SOC 2" usually means security; a buyer with a formal program will tell you which categories they expect.
## The observation window: what is convention, and what is a rule
This is the single most misreported thing about SOC 2, and it is worth being exact.
**No AICPA standard, criteria document, or guide prescribes a minimum observation period for a Type 2.** We checked the currently effective attestation standards, the trust services criteria, and the description criteria. There is no minimum in any of them. Pages telling you that a Type 2 "requires a minimum six-month testing period" are stating a rule that does not exist.
What the AICPA actually says is more useful. Under its SOC 2 Guide, **service organization management determines the time frame** the examination covers. The service auditor then has to judge, before accepting the engagement, whether sufficient appropriate evidence of operating effectiveness is likely to be available over that period — and the Guide offers a period of *less than two months* as an example of one where an auditor might reasonably conclude it is not. That is a judgement framework, not a threshold.
So where do three, six and twelve months come from? Convention. Three months is the shortest window we see auditors and buyers routinely accept; six is the most common; twelve aligns neatly with an annual cycle and is what a mature program usually settles into. Those are our observations from practice, not figures published by the AICPA, and you should treat any specific number — including ours — as a market norm to confirm with your auditor and your customer rather than a requirement.
One thing that *is* fixed: **the window starts when your controls are operating and you are collecting evidence**, not when you sign with an auditor. Nothing before that day counts.
## The timing mistake
The most expensive mistake is starting the week procurement asks. By then you are negotiating from behind: the buyer has a deadline, you do not have a report, and the only lever left is a discount.
The second most expensive mistake is skipping Type 1 to "save money" and going straight to Type 2 before the controls have operated. You cannot test six months of a control that has existed for three weeks. The observation window starts when the controls do.
## A sequencing that works
1. **Readiness first.** Know your gaps before an auditor finds them. That is what the scorecard on this site is for.
2. **Fix the critical three** — access reviews, joiner and leaver records, and evidence collection — because in our experience they produce the most first-year exceptions.
3. **Type 1** as soon as the controls are designed and documented. Use it to close the deal that is waiting.
4. **Start the observation window the same day.** Some months later you have a Type 2 without a second readiness project.
If you cannot tell which step you are on, take the scorecard. It will show you where you are. If you have a date from a customer and want to know whether it is still reachable, the [SOC 2 Timeline Calculator](/tools/soc-2-timeline-calculator/) maps the ranges against it.
Sources cited:
- AICPA SSAEs — currently effective (AT-C section 105, Concepts Common to All Attestation Engagements; AT-C section 205, Assertion-Based Examination Engagements) — AICPA & CIMA: https://www.aicpa-cima.com/resources/download/aicpa-ssaes-currently-effective
- TSP Section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus — 2022) — AICPA Assurance Services Executive Committee: https://assets.ctfassets.net/rb9cdnjh59cm/5jT1narHNQNzt4JGlkd1gr/248661d08e42531329d147782a6f8854/Trust-services-criteria.pdf
- System and Organization Controls: SOC Suite of Services — AICPA & CIMA: https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
Questions and answers:
Q: Is there a minimum observation period for a SOC 2 Type 2?
A: No. No AICPA standard, criteria document or guide prescribes a minimum period. Under the AICPA's SOC 2 Guide, service organization management determines the time frame the examination covers, and the service auditor judges whether sufficient evidence of operating effectiveness is likely to be available over it. Three months is a market convention, not a rule — and any page telling you six months is required is stating something the standards do not say.
Q: Can a Type 1 be enough to close an enterprise deal?
A: Sometimes, and more often than founders expect. A Type 1 gives a buyer's security team something dated and independent to attach to the risk file. Whether it clears their bar is a question about their third-party risk policy, not about the report — so ask them directly rather than guessing.
Q: Do I have to do a Type 1 before a Type 2?
A: No, a Type 1 is not a prerequisite. It is useful when you need something in a buyer's hands before an observation window can realistically close, and it is wasted money if you have already been operating and evidencing controls long enough to go straight to a Type 2.
Q: When does the observation window actually start?
A: When your controls are operating and you are collecting evidence for them — not when you sign an engagement letter and not when you start a readiness project. Nothing before that day counts toward the window, which is why engaging an auditor early does not by itself move a Type 2 date forward.
Q: What is the difference between SOC 1, SOC 2 and SOC 3?
A: SOC 1 addresses controls relevant to a customer's internal control over financial reporting. SOC 2 addresses the trust services criteria — security, and optionally availability, processing integrity, confidentiality and privacy. SOC 3 is a short, freely distributable version of a SOC 2 without the detailed testing results.
---
### First year public: the SOX 404 timeline nobody hands you
URL: https://thecleanopinion.com/articles/sox-404-first-year-timeline/
Category: SOX 404
Published: 2026-08-20. Updated: 2026-09-10.
Author: The Clean Opinion
Which fiscal year your first management assessment actually applies to, why the answer turns on reporting history rather than your IPO date, and where newly listed companies run out of time.
Nobody hands a newly public company a calendar for Section 404. The obligation is real, the dates are derivable, and the work behind them is neither obvious nor small. Here is the timeline to work from — and, first, the question most companies get wrong.
## Which year does this actually apply to?
Section 404(a) requires management to assess and report on the effectiveness of internal control over financial reporting. Section 404(b) requires the external auditor to attest to it. The question is when the first one bites.
**The answer does not turn on your IPO date.** Instruction 1 to Item 308 of Regulation S-K reads:
> "A registrant need not comply with paragraphs (a) and (b) of this Item until it either had been required to file an annual report pursuant to section 13(a) or 15(d) of the Exchange Act for the prior fiscal year or had filed an annual report with the Commission for the prior fiscal year."
Three things follow, and each one catches somebody:
1. **The relief covers both paragraphs — (a) and (b).** The first annual report generally carries neither management's report nor the auditor's attestation. Instead it carries a prescribed statement saying so, "due to a transition period established by rules of the Securities and Exchange Commission for newly public companies."
2. **The test is prior-year reporting history, not recency of listing.** A company whose equity IPO is its first *listed* offering but which already filed a Form 10-K — reporting under Section 15(d) from an earlier registered debt offering, say, or having registered on Form 10 — has already filed an annual report for the prior fiscal year, and does not get the relief.
3. **A de-SPAC is generally not a newly public company.** The registrant is the SPAC, which has been reporting for some time. SEC staff has addressed this directly in Regulation S-K C&DI 215.02: the surviving issuer in a reverse acquisition "is not a 'newly public company'." The staff said it would not object to the surviving issuer omitting management's assessment in the Form 10-K covering the fiscal year the transaction closed — but that is a conditional staff accommodation, it does not apply where the transaction closes shortly after year-end and an amended Form 8-K updates the year-end financials, and it does not relieve the Section 302 certification language.
If you went public through a merger with a shell, assume you are a year earlier than the IPO-based arithmetic suggests until securities counsel tells you otherwise.
## What 404 actually requires
**404(a), every year, for everyone in scope.** Rule 13a-15(c) requires management to evaluate the effectiveness of ICFR as of the end of each fiscal year, and Item 308(a) requires the report to state management's responsibility, identify the framework used, and give the assessment.
Two provisions inside that are worth pinning up:
- **You cannot conclude "effective" with a material weakness outstanding.** Item 308(a)(3): "Management is not permitted to conclude that the registrant's internal control over financial reporting is effective if there are one or more material weaknesses."
- **You have to be able to show your work.** Instruction 2 to Item 308: "The registrant must maintain evidential matter, including documentation, to provide reasonable support for management's assessment."
**The framework is your choice, within limits.** Rule 13a-15(c) requires "a suitable, recognized control framework that is established by a body or group that has followed due-process procedures, including the broad distribution of the framework for public comment." It does not name COSO. Almost everyone uses COSO. The rule also provides that an evaluation conducted in accordance with the SEC's 2007 interpretive guidance — Release 33-8810, which sets out a top-down, risk-based approach — will satisfy the requirement.
**404(b) depends on filer status, and on not being an EGC.** Item 308(b) requires the auditor's attestation where the registrant is an accelerated or large accelerated filer *and* is not an emerging growth company. Both gates matter: an EGC that is a large accelerated filer still has no attestation requirement.
> **A correction worth making, because it appears everywhere.** "Smaller reporting companies are exempt from 404(b)" is wrong as written. The exemption attaches to **non-accelerated filer** status. The two categories overlap but are not the same: a smaller reporting company with a float between $250 million and $700 million and revenues of $100 million or more is an accelerated filer, and 404(b) applies to it. The 2020 amendments in Release 34-88365 widened who qualifies as non-accelerated — describing the result as issuers that "will remain obligated … to establish and maintain ICFR and have management assess the effectiveness of ICFR, but they will not be required to have their management's assessment … attested to, and reported on, by an independent auditor." Check status against Rule 12b-2 each year.
## The four things that have to exist
1. **A documented control environment.** Entity-level controls: who approves what, how the board oversees, how issues are escalated.
2. **Process-level documentation** for every significant account and disclosure — flowcharts or narratives that show where a number can go wrong and what stops it.
3. **IT general controls over the systems those processes depend on**: access, change management, operations. This is where most first-year findings live, and it is a defined term — the AICPA's SAS No. 145 defines general IT controls and lists user-access reviews, provisioning, deprivileging and change migration among them.
4. **Evidence that the controls operated** — not just existed — for the period under assessment. See Instruction 2 above; this is the part that cannot be reconstructed at the end.
## Where companies run out of time
- **ITGCs are discovered late.** Finance owns SOX; IT owns the systems. The gap between them is where the exceptions are.
- **Remediation has a lag.** A control fixed in month ten only has two months of operation to test. This is the single most common reason a first-year assessment lands badly: not that the gap was unknown, but that it was closed too late to demonstrate operation.
- **Spreadsheets count.** If a material number lives in Excel, that spreadsheet is information used in a control and needs controls of its own.
- **Turnover.** The person who designed the control leaves; the evidence leaves with them.
## A working calendar
This is a practitioner calendar — **our working plan, not a schedule published by the SEC or the PCAOB.** No rule sets these intervals. Your auditor's plan and your own complexity will compress or extend them, and if you are in 404(b) the auditor's own timetable under PCAOB AS 2201 will shape the back half.
| Months before year-end | What should be done |
|---|---|
| 12+ | Scoping: significant accounts, locations, systems |
| 9–12 | Process and ITGC documentation; walkthroughs; gap list |
| 6–9 | Remediation of design gaps; controls begin operating |
| 3–6 | Management testing; fix operating failures while there is still runway |
| 0–3 | Auditor fieldwork; roll-forward testing |
The shape matters more than the specific months: everything that has to *operate* has to start early enough to be tested, and management's own testing has to leave room to fix what it finds.
## What to do first
1. **Settle which fiscal year is your first assessment year**, in writing, with counsel — using reporting history, not the IPO date, and with the de-SPAC question asked explicitly.
2. **Name one person accountable for ITGC evidence** across every in-scope system. Finance and IT each assuming the other has it is the most reliable source of first-year exceptions.
3. **Start the access-review and change-management evidence now**, whatever month you are in, because those controls have to operate across a period and no amount of later effort creates history.
If you are reading this partway through the year, the [SOX 404 deadline calculator](/tools/sox-404-deadline-calculator/) works out which year-end to plan against and lays the milestones back from it, and the [readiness scorecard](/scorecard/?framework=sox) will tell you which gaps are still fixable in time.
Sources cited:
- Sarbanes-Oxley Act § 404, codified at 15 U.S.C. § 7262 — Management assessment of internal controls — Office of the Law Revision Counsel, U.S. House of Representatives: https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title15-section7262&num=0&edition=prelim
- 17 CFR 229.308 (Item 308) — Internal control over financial reporting, including the Instructions to Item 308 — Electronic Code of Federal Regulations: https://www.ecfr.gov/current/title-17/part-229/section-229.308
- 17 CFR 240.13a-15 — Controls and procedures — Electronic Code of Federal Regulations: https://www.ecfr.gov/current/title-17/part-240/section-240.13a-15
- 17 CFR 240.12b-2 — Definitions (accelerated filer, large accelerated filer, smaller reporting company) — Electronic Code of Federal Regulations: https://www.ecfr.gov/current/title-17/part-240/section-240.12b-2
- Commission Guidance Regarding Management's Report on Internal Control Over Financial Reporting (Release No. 33-8810) — U.S. Securities and Exchange Commission: https://www.sec.gov/files/rules/interp/2007/33-8810.pdf
- Division of Corporation Finance, Compliance and Disclosure Interpretations: Regulation S-K — see Question 215.02 on reverse acquisitions — U.S. Securities and Exchange Commission: https://www.sec.gov/rules-regulations/staff-guidance/corporation-finance-interpretations/regulation-s-k
- Accelerated Filer and Large Accelerated Filer Definitions (Release No. 34-88365) — U.S. Securities and Exchange Commission: https://www.sec.gov/files/rules/final/2020/34-88365.pdf
- AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements — Public Company Accounting Oversight Board: https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201
Questions and answers:
Q: Does my first annual report after the IPO need a management report on internal control?
A: Generally no. Instruction 1 to Item 308 of Regulation S-K says a registrant need not comply until it has either been required to file, or has filed, an annual report for the prior fiscal year — and the relief covers both management's report and the auditor attestation. The first annual report carries a prescribed statement explaining the omission instead.
Q: Does that relief apply to a de-SPAC?
A: Generally not, and this is the most expensive misunderstanding in this area. The registrant in a de-SPAC is the SPAC, which already has a reporting history, so the surviving company is not a newly public company. SEC staff has said it would not object to omitting management's assessment for the fiscal year the transaction closed, but that is a conditional staff position rather than an entitlement — and it is unavailable where the deal closes shortly after year-end and an amended Form 8-K updates the year-end financials.
Q: Are smaller reporting companies exempt from the auditor attestation?
A: Not as such — the exemption attaches to non-accelerated filer status, not to smaller reporting company status, and the two are not the same. A smaller reporting company with a public float between $250 million and $700 million and annual revenues of $100 million or more can be an accelerated filer, and then 404(b) applies. Check filer status against Rule 12b-2 rather than assuming.
Q: Which control framework do we have to use?
A: The rule does not name one. Rule 13a-15(c) requires the evaluation to be based on a suitable, recognized control framework established by a body that followed due process including public comment. COSO's Internal Control — Integrated Framework is the one almost everyone uses, and the SEC's 2007 interpretive guidance in Release 33-8810 describes an approach that satisfies the evaluation requirement.
Q: What happens if we find a material weakness?
A: Management cannot conclude that internal control over financial reporting is effective. Item 308(a)(3) is explicit: management is not permitted to reach an effective conclusion if one or more material weaknesses exist, and the weakness has to be disclosed. This is why finding problems in month ten rather than month three matters so much.
---
### How to run an access review an auditor will accept
URL: https://thecleanopinion.com/articles/access-review-auditor-will-accept/
Category: SOC 2
Published: 2026-08-18. Updated: 2026-09-10.
Author: The Clean Opinion
Incomplete access reviews are the exception we see most often in a first-year SOC 2. Here is what the criteria actually require, what they leave to you, and what evidence survives testing.
The one control worth looking at on day one of an engagement is the access review. Not because it is the most important control — because it is the one that shows how the company really operates. A company that reviews access on a calendar, with a named approver, and keeps the evidence, usually does everything else properly too.
## A note on "the most common exception"
You will read a lot of confident claims about which control produces the most first-year SOC 2 exceptions, including an earlier version of this article. It is worth being straight about the status of that claim.
**Nobody can source it, and we could not source ours either.** SOC 2 reports are distributed to customers under non-disclosure agreements. There is no public corpus of them to count, the way there is with SEC filings, so no study of SOC 2 exception rates exists — not from the AICPA, not from academia, and not behind the vendor blog posts that rank them. What those posts are describing is one firm's caseload, which is a reasonable thing to have an opinion from and not a statistic.
So: **in our practice, incomplete or undocumented user access reviews are the exception we see most often in a first-year SOC 2.** Treat that as observation, not measurement.
The nearest thing to real data comes from the adjacent SOX world, where filings are public and can be counted. In Ideagen Audit Analytics' nineteen-year review of SOX 404 disclosures, information technology issues were cited in **54.5% of adverse ICFR auditor attestations for FY2022** — the top issue that year, and the first time in five years IT had taken the top spot. The same report finds that an ICFR disclosure is, on average, **three times more likely to be adverse during a first-time assessment**. Different framework, different population, same shape of problem: IT controls, and the first year is the hard one.
## What the criteria actually say
Access reviews sit under two of the trust services criteria, and they cover different things — a distinction worth getting right, because saying "CC6.2 or CC6.3" reads like someone who has not opened the document.
**CC6.2** is about credentials and accounts. The criterion reads, in part, that "prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users," and that "user system credentials are removed when user access is no longer authorized."
**CC6.3** is about roles, entitlements and rules: the entity "authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties."
Here is the nuance most articles miss. **Periodic review is not in either criterion.** It appears in the *points of focus* underneath them — under CC6.2, "the entity reviews access credentials on a periodic basis for validity"; under CC6.3, "the appropriateness of access roles and access rules is reviewed on a periodic basis." The AICPA is explicit that using the criteria does not require an assessment of whether each point of focus is addressed.
That is not a loophole. An auditor still has to form an opinion on CC6.2 and CC6.3, and a periodic review is the ordinary way a company demonstrates that access remains authorized and appropriate. But it does mean the accurate sentence is "the points of focus call for periodic review," not "CC6.3 requires a quarterly access review" — which is a rule nobody wrote.
**And nothing anywhere specifies a frequency.** The criteria say "periodic." NIST SP 800-53 requires you to "review accounts for compliance with account management requirements" at an *organization-defined frequency*, and to review assigned privileges at an organization-defined frequency under AC-6(7). NIST's Cybersecurity Framework 2.0 says access permissions are "defined in a policy, managed, enforced, and reviewed." None of them says quarterly. What they require is that you pick an interval and meet it.
Access reviews are also, formally, an IT general control. The AICPA's SAS No. 145 defines general IT controls and lists example ITGCs by process — "user-access reviews: controls to recertify or evaluate user access for ongoing authorization over time" appears by name.
## Why reviews fail the test
Most companies *do* review access. The exception comes from one of four things:
1. **No named approver.** "The team looked at it" is not testable. One person signs.
2. **No evidence.** The review happened in a meeting; nothing was retained.
3. **No action trail.** Accounts were flagged for removal; nobody can show they were removed.
4. **Wrong population.** The review covered the application but not the database, the cloud console, or the deploy pipeline.
The fourth is the one that surprises people. An access review over the application while the engineers hold standing credentials to the database underneath it does not tell an auditor what it needs to know, and a reviewer who knows the stack will ask.
## The minimum that passes
This is our recommendation, built from what survives testing — not a standard:
- **Quarterly**, on a calendar, for production systems that touch customer data. Pick the interval deliberately, write it in the policy, and then hold to it; an interval you miss is worse than a longer one you keep.
- **A system-generated export** of users and permissions — not a hand-typed list. The population is the first thing an auditor reperforms.
- **One named reviewer** per system who understands what the permissions mean. Not the CFO by default; the person who can say whether this engineer should still have production write access.
- **A ticket** that records the review, the decisions, and the removals, with a completion date.
- **Follow-through within a defined window** — five business days is a reasonable target. Define it, then meet it.
- **Privileged accounts reviewed separately**, and service accounts included. Shared and service accounts are where reviews most often go quiet.
## Evidence an auditor will ask for
| Request | What satisfies it |
|---|---|
| Population of systems in scope | A list, with an owner for each |
| Proof the review occurred | The export, the ticket, the sign-off, dated |
| Proof of action | Tickets or logs showing removals |
| Consistency | The same thing, every period, across the observation window |
Three quarters of this, done the same way, is a clean control. One good quarter and two spreadsheet quarters is an exception — not because spreadsheets are disallowed, but because the inconsistency is what the auditor samples into.
If you are not sure whether your current process would survive that, the [readiness scorecard](/scorecard/?framework=soc2) asks the same question an auditor would, and [Type 1 vs Type 2](/articles/soc-2-type-1-vs-type-2/) explains why the consistency across a window matters more than any single quarter.
Sources cited:
- TSP Section 100, 2017 Trust Services Criteria (With Revised Points of Focus — 2022) — see CC6.2 and CC6.3 — AICPA Assurance Services Executive Committee: https://assets.ctfassets.net/rb9cdnjh59cm/5jT1narHNQNzt4JGlkd1gr/248661d08e42531329d147782a6f8854/Trust-services-criteria.pdf
- Statement on Auditing Standards No. 145, Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement (AU-C section 315) — Appendix F — AICPA Auditing Standards Board: https://assets.ctfassets.net/rb9cdnjh59cm/36dIstmjNFLm48jrBBHD92/f9bdb47a639348a3ebb08328f60e0496/sas-145.pdf
- NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations — AC-2 Account Management, AC-6(7) Review of User Privileges — National Institute of Standards and Technology: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf
- The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29) — PR.AA-05 — National Institute of Standards and Technology: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- SOX 404 Disclosures: A 19-Year Review, 2004–2022 — Ideagen Audit Analytics: https://www.auditanalytics.com/doc/SOX_404_Disclosures_A_Nineteen-Year_Review.pdf
Questions and answers:
Q: How often does a SOC 2 access review have to happen?
A: No framework in this area sets a frequency. The trust services criteria say access roles and rules are reviewed on a periodic basis; NIST SP 800-53 leaves the interval as an organization-defined frequency. Quarterly is a convention and our own recommendation, not a requirement — what matters is that you define an interval, and then meet it every time.
Q: Which trust services criteria do access reviews map to?
A: Both CC6.2 and CC6.3, and they cover different objects. CC6.2 concerns registering and authorizing users and removing credentials when access is no longer authorized. CC6.3 concerns authorizing, modifying and removing access to assets with regard to least privilege and segregation of duties. Most real access reviews touch both.
Q: Is a periodic access review actually required by the criteria?
A: Strictly, periodic review appears in the points of focus beneath CC6.2 and CC6.3 rather than in the criterion text itself, and the AICPA is explicit that using the criteria does not require assessing whether each point of focus is addressed. In practice, an auditor forming an opinion on CC6.2 and CC6.3 will expect to see how you satisfy yourself that access remains appropriate — and a periodic review is the usual answer.
Q: What evidence does an auditor actually test?
A: A system-generated population of users and permissions, a named reviewer's sign-off, a record of the decisions made, and proof that the removals happened — with dates that line up. A review that produced no removals is fine if that is genuinely the answer; a review that flagged accounts nobody can show were removed is an exception.
Q: Does a spreadsheet review count?
A: It can, if the population came out of the system rather than being typed by hand, one named person signed it, and the follow-up actions are traceable. What fails testing is not the spreadsheet — it is the missing population, the absent approver, and the removals nobody can evidence.
---
## Tool and scorecard methods
### Security Questionnaire Panic Checker
URL: https://thecleanopinion.com/tools/security-questionnaire-panic-checker/
What is a security questionnaire actually asking for?
Most vendor security questionnaires cover the same eight areas in different words. This checker sorts each line you paste into one of those areas by keyword, shows how the questions are distributed, lists the evidence a reviewer will want for each area, and flags the answers that are dangerous to guess at.
How it works:
Each pasted line is matched against 134 fixed keyword and regular-expression patterns grouped into eight control areas — audit evidence, access control, encryption, incident response, vendor management, privacy and data handling, business continuity, and change management — and filed under the single area whose patterns it matched most. It is deterministic pattern matching, not a language model, and it reads the questionnaire rather than your controls.
Because a line is filed under exactly one area, a question spanning two areas is counted once. And any line containing a trigger word is counted, including a section header, a cover page, or a line from an answer column. The number reported is a count of lines kept, not a count of questions.
Lines that match nothing are not discarded silently — they are listed back, so a real control question in an unusual phrasing can still be spotted. There is no category for risk assessment, personnel security, training, governance or physical security, so questions on those subjects land in that unmatched list rather than in a control area.
Urgency is scored from what you enter alongside the paste: whether a live deal depends on it, how far away the customer's deadline is, whether SOC 2 is being asked for and what you hold today, how many areas the questionnaire covers, who sent it, and your headcount. It is a reading of the situation you described, not of your control environment. If nothing in the paste matched a control area at all, a high score is capped at medium, because urgency built on text the checker could not read would be a false alarm.
The evidence list and the likely gaps are fixed text per area, not findings about your company. Every company pasting an access-control question receives the same access-control gap. The weights that rank those gaps are the practitioner judgement of the auditors who wrote them; no measured exception-rate dataset sits behind them.
Questions and answers:
Q: Does this use AI to read my questionnaire?
A: No. It runs 134 fixed keyword and regular-expression patterns and files each line under whichever area matched most. It cannot tell a question from an answer, or a heading from either, and the tool labels itself rule-based for exactly that reason.
Q: Does anything I paste get sent anywhere?
A: The analysis runs entirely in your browser and the questionnaire text never leaves it — the text is not included even when you request the PDF. Requesting the PDF does send the summary, the area counts and your contact details, so the report can be emailed to you.
Q: Why does it say “questions read” when some of those lines are not questions?
A: The number counts lines kept after noise is stripped, which includes headings, instructions, and any answers already filled in. Read it as how much text was sorted, rather than as a count of questions asked.
Q: Do the eight areas match the SOC 2 Trust Services Criteria?
A: No. They are this tool's own grouping of what vendor questionnaires tend to ask about, and they do not map onto the criteria one to one. There is no category for risk assessment, personnel security, training, governance or physical security.
Q: Are the likely gaps findings about my company?
A: No. They are fixed paragraphs attached to whichever areas the questionnaire covered, ranked by the auditors' judgement of where first-year exceptions usually appear. The tool never sees a control of yours and cannot know what you already hold.
---
### SOC 2 Timeline Calculator
URL: https://thecleanopinion.com/tools/soc-2-timeline-calculator/
How long does a SOC 2 audit take?
There is no single answer — it depends almost entirely on how much is already in place. This calculator turns nine answers about your controls into three dated ranges: when a Type 1 could be ready, when a Type 1 report could be in hand, and when a Type 2 could be, then compares each against your customer's deadline.
How it works:
Five control areas carry a remediation cost in weeks: written policies, access reviews, vendor reviews, an incident response plan, and evidence collection. Each is answered yes, partial or no. A missing policy set counts six weeks and a partial one three; access reviews four and two; vendor reviews three and two; incident response three and two; evidence collection four and two.
Those weeks are not added up. Gaps get worked in parallel, so the estimate takes the single longest gap and adds half of everything else. Systems beyond a baseline of five add 0.4 weeks each, capped at eight weeks in total. Where nobody owns the programme, the whole remediation figure is multiplied by 1.4 and two more weeks are added, because unowned readiness work starts later and runs slower.
A floor of two weeks applies even when every answer is yes, since scoping, scheduling and pulling a point-in-time evidence set take that long regardless. The high end of every range is its low end multiplied by 1.4, plus one week. A Type 1 then adds two weeks of fieldwork and two weeks of report drafting; a Type 2 adds three and three.
A Type 2 also needs an observation window, and this is where most timelines go wrong. Three calendar months are added to the early end of the Type 2 range and six to the late end. That spread is not an error bar — the two ends are two different scoping decisions, a three-month window and a six-month one. Three months is what most auditors and buyers accept in practice; it is a convention rather than a figure published by the AICPA.
The observation clock starts the day controls are operating and evidence is being collected, not the day an auditor is engaged. Nothing before that day counts toward the window.
A customer deadline moves none of the dates. It is compared with the relevant range and reported as on track when it falls on or after the end of that range, tight when it falls inside it, and likely late when it falls before the range begins. That rule is deliberately unforgiving and has no tolerance either side.
Every constant here is a stated planning assumption drawn from practice, not a figure from a standard. None comes from the AICPA's attestation standards, from the trust services criteria, or from a published survey, and all of them are printed alongside the result so the arithmetic can be checked or argued with.
Questions and answers:
Q: Where do these week counts come from?
A: From the practice of the auditors who built the calculator. Not one of them is drawn from the AICPA's attestation standards or from a published survey — no such survey exists, because SOC 2 reports are distributed under NDA and there is no public corpus to measure. The assumptions are printed next to the result so you can see exactly what was applied and disagree with it.
Q: Why is the Type 2 range so wide?
A: Because its two ends assume different observation windows — three months at the early end, six at the late end. It is not a margin of error, so splitting the difference is the wrong reading. Decide which window you are planning for and use that end.
Q: Does the observation window start when I sign with an auditor?
A: No. It starts the day your controls are operating and you are collecting evidence for them. Nothing before that day counts, which is why signing an engagement letter early does not move a Type 2 date forward on its own.
Q: Does my customer deadline change the estimate?
A: Not at all. The deadline is compared against the estimated range and nothing more. The calculator does not compress the plan, model a rush engagement, or trade cost against time when a date is close.
Q: Can it tell me whether I would pass?
A: No. It estimates when a report could realistically be in hand given what you said about your controls. It is a planning estimate, not an audit opinion, not a readiness assessment, and not a commitment on any auditor's calendar.
---
### SOX 404 Deadline Calculator
URL: https://thecleanopinion.com/tools/sox-404-deadline-calculator/
When does your first SOX 404 assessment actually apply?
Not on the date you went public. This calculator works out the first fiscal year-end that management's Section 404(a) assessment plausibly applies to, then lays out a working first-year calendar backwards from it. It produces a year-end to plan against, not a filing deadline, and it does not determine your filer status.
How it works:
The starting point is the first fiscal year-end falling on or after your public-company date, which is taken as the period your first annual report covers. Entering the date that annual report was or will be filed pins the period down directly instead of deriving it.
One fiscal year is then added, and this is the single most consequential assumption made here: that the transition relief for newly public companies applies. Instruction 1 to Item 308 of Regulation S-K suspends both management's report and the auditor attestation until the registrant has either been required to file, or has filed, an annual report for the prior fiscal year. The legal test is that reporting history, not how recently the company listed — so a de-SPAC survivor, whose registrant is the SPAC, is generally not treated as a newly public company at all, and a company with a prior filed annual report does not get the relief either. Those companies have a first assessment year a full year earlier than this arithmetic produces, and nothing here can detect the case. It is the assumption to confirm with securities counsel before relying on any date.
Seven milestones are laid out backwards from the year-end being planned against: scoping at twelve months, the risk-control matrix at eleven, documentation and walkthroughs at nine, design testing at eight, remediation closing at six, management's operating-effectiveness testing at three, and the assessment itself at year-end. That spacing is a working practitioner calendar rather than a regulatory schedule, and an auditor's plan may compress or extend it.
Where the year-end that comes out of this is fewer than ninety days away, it is treated as too close to plan a first-year programme against. It is reported separately, along with the milestones that would already have passed, and the plan moves to the following year-end.
Filer status is read back, never determined. Whatever is selected is taken at face value and used only to phrase a caveated note on the Section 404(b) auditor attestation. It is never checked against the revenue or public float entered, and it changes no date, no milestone and no rating. That note carries a standing caveat that the SEC's May 2026 proposal, Release 33-11419, would eliminate the accelerated filer and smaller reporting company categories altogether; the calculator applies the rules as they stood when it was last reviewed rather than the proposal.
A separate ITGC reading comes from four answers: whether one person owns ITGC evidence, the state of access-review and change-management evidence, and how many financial systems are in scope. It is a nine-point heuristic over those four answers and nothing else. It says nothing about the calendar, the scoping, or the financial controls themselves.
Sources:
- 17 CFR 229.308 (Item 308) — Internal control over financial reporting — Electronic Code of Federal Regulations: https://www.ecfr.gov/current/title-17/chapter-II/part-229/subpart-229.300/section-229.308
- Release 33-11419 — Enhancement of Emerging Growth Company Accommodations and Simplification of Filer Status for Reporting Companies (proposed rule) — U.S. Securities and Exchange Commission: https://www.sec.gov/files/rules/proposed/2026/33-11419.pdf
Questions and answers:
Q: Is this my 10-K filing deadline?
A: No. It produces a fiscal year-end that management's first Section 404(a) assessment plausibly applies to. The filing deadline for the annual report itself, which depends on filer status, is not calculated anywhere in this tool.
Q: Does it tell me whether 404(b) auditor attestation applies?
A: No. It takes the filer status you select at face value and reads back a caveated note on what that status generally means. Filer status is determined by SEC rules applied to your own numbers, and the calculator never checks your selection against the revenue or public float you enter.
Q: What if the transition relief does not apply to us?
A: Then the year-end shown is a year late. The relief keys off whether a prior-year annual report was filed, not off the listing date, so a de-SPAC survivor — where the registrant is the SPAC, which has been reporting for some time — is generally not a newly public company. Nothing in the arithmetic detects that. Confirm it with securities counsel before planning against any date here.
Q: Where does the milestone calendar come from?
A: It is a working first-year calendar written from practice, not a schedule published by a regulator or a standard-setter. Your auditor's plan and your own complexity may compress or extend every date in it.
Q: Why does it read high urgency when I have over a year?
A: Because the reading reflects posture as well as time. No named ITGC owner combined with missing evidence reads high even with fifteen months of runway, since the evidence has to operate for enough of the period to be tested and every month without it shortens the testable window.
---
### Breach Aftermath Control Checklist
URL: https://thecleanopinion.com/tools/breach-aftermath-control-checklist/
What will auditors, insurers and your board ask for after a breach?
The second wave of a breach is questions. This checklist takes eight answers about the incident and selects, from a fixed library, the controls to review, the evidence to gather, and the questions each party — customers, your cyber insurer, the board, your auditor, lenders — tends to ask, alongside the artifact that answers each one.
How it works:
Eight answers about the incident — its type, whether customer or personal data was involved, whether financial systems were touched, whether a vendor was involved, whether ransomware was involved, whether anything has been disclosed publicly, who is already asking questions, and what remediation evidence exists — select items from a fixed library of forty-five checklist items, forty-one stakeholder questions and thirteen worksheet rows. Nothing is written per incident, and roughly half the control-review items appear for everyone.
The score is a weighted count of how much follow-up scrutiny those answers imply, and it is dominated by who is already asking: each party is worth fourteen points out of a hundred. Financial systems touched is twenty, a public disclosure eighteen, ransomware sixteen, customer data ten, and no remediation evidence fourteen. Fifty or more reads high, twenty-five or more medium. Every term is itemised in the result, so the arithmetic can be checked.
One override sits on top of those bands: a confirmed exposure of customer or personal data can never read as low urgency and is raised to medium regardless of the total. A result can therefore read medium at a score of ten. The score itself is deliberately left alone, so the published weighting stays true.
An item marked critical means a party who is already asking will raise it — not that it is the most severe thing on the list. The warning about how the incident timeline and root-cause analysis are commissioned is arguably the highest-stakes item, and it is marked critical only when the board or the auditor is among those asking.
Nothing here is legal advice, and no notification obligation is decided. Which notification clocks may be running, whether anything is material, and whether a disclosure is required are all routed to counsel. This is preparation for the period after the immediate response is under control; during a live incident, counsel and an incident-response provider come first.
Questions and answers:
Q: Is this an incident response tool?
A: No, and it should not be used as one. It prepares for the questions that follow, once the immediate response is under control. In a live incident your counsel and your incident-response provider come first, and the checklist says so in its own words.
Q: Does it tell me whether I have to notify anyone?
A: No. It tells you to ask counsel which notification clocks may already be running, and names the classes of obligation to put in front of them. Which ones apply to your facts is a legal determination the checklist deliberately refuses to make.
Q: Is the score a measure of how bad the breach is?
A: No. It measures how much follow-up scrutiny your answers imply, and it is dominated by how many parties are already asking. A minor incident where all five parties are asking scores higher than a confirmed ransomware event that nobody has asked about yet.
Q: What does a flagged item mean?
A: That a party you said is already asking will raise it. It describes a relationship to who is asking, not a severity ranking — a high-stakes item can appear unflagged simply because the party who cares about it has not come knocking yet.
Q: Does it know anything about my incident beyond the eight answers?
A: Nothing at all. There is no log ingestion, no integration, and no document upload. Every word it prints was written in advance, and your answers only decide which of those words are selected.
Q: Is the insurer section based on my policy?
A: No. It reflects what cyber insurers commonly ask about after an incident, written from practice. It is not a reading of your policy, your coverage or your carrier's requirements, none of which are visible to the checklist.
---
### Trust Page Grader
URL: https://thecleanopinion.com/tools/trust-page-grader/
What should a trust page include?
Ten things, in roughly the order enterprise reviewers look for them: an audit report, a trust page or security overview, a privacy policy, a subprocessor list, a way to request evidence, a security contact, a status page, a vulnerability disclosure path, an incident response process, and data retention and deletion.
How it works:
You paste the text of your trust or security page and it is graded locally, in your own browser. The URL field is a label for the report header only — no page is ever fetched, by your browser or by a server — so a URL on its own grades nothing.
Ten completeness checks run over the pasted text, each owning a list of keyword patterns, fifty-five in total. A check is credited the first time any one of its patterns matches somewhere that is not negated. The ten weights sum to a hundred: an audit report is worth eighteen, a trust page or security overview twelve, then privacy policy, subprocessor list and evidence process at ten each, and security contact, status page, vulnerability disclosure, incident response and data retention at eight each.
Negation is honoured. A match is discarded when a negating word appears within the ten words before it, so a page saying it has no status page is not credited with one. Where a check's only matches were negated, the page's own sentence is quoted back as an admission rather than counted as present.
Scoring is a plain sum of the weights credited — no partial credit, no penalties, and no interaction between checks. Eighty-five or more is a complete page, seventy a mostly complete one, fifty partial, thirty thin, and under thirty is not yet a trust page. The two questions about who your buyers are steer the urgency and the notes; they never move the score.
Separately, thirteen phrase rules flag claims that tend to invite harder questions than they answer: absolute language, framework names used as though they were certifications, and promises of security that cannot be evidenced. These are wording flags, not findings. The grader cannot tell whether a claim is true, and it will flag an accurate statement that is merely imprecisely worded. They never affect the score.
What the grade measures is the page, not the company. A perfect hundred means ten families of keywords appeared in the text pasted, and it is fully reachable by a page that simply says it has all ten things. It is not an audit, not an assessment of controls, and says nothing about whether a company is secure.
Questions and answers:
Q: Can I just enter my URL?
A: No. The page is never fetched, and the URL field only labels the report header. Select the text of your trust page and paste it in — HTML is fine, and the markup gets stripped before anything is graded.
Q: Does a high score mean my company is secure?
A: No. It means ten families of keywords appeared in the text you pasted. A page can reach a hundred by claiming all ten things, and the grader has no way to check that any referenced document exists, is current, or covers what it says it covers.
Q: Where do the weights come from?
A: They are the editorial judgement of the auditors who built the tool about what enterprise reviewers look for first. They are not derived from a standard, a framework, or a survey of trust pages, and they are published so you can disagree with them.
Q: What does a flagged claim mean?
A: That a phrase tends to invite harder questions than it answers — never that it is false. The grader cannot assess truth, and it will flag an accurate statement that is only imprecisely worded, such as writing “ISO 27001 compliant” when you actually hold the certificate.
Q: Does my pasted page get sent anywhere?
A: The grading runs entirely in your browser and the paste never leaves it. If you request the PDF, the result is sent so the report can be emailed — and the result contains short excerpts of your page, including the flagged phrases.
Q: Is the ten-item list everything a buyer will ask about?
A: No. It is a deliberate shortlist of what this grader checks. Encryption, access control, business continuity, penetration-test cadence and security training are questionnaire staples that are not checked here at all.
---
### Readiness scorecard
URL: https://thecleanopinion.com/scorecard/
How is the readiness score calculated?
Ten questions, each answered on a four-point scale worth zero to three points. Your points are taken as a share of the maximum and expressed out of ten. Answering zero on a question marked critical raises a critical flag, which holds the verdict back no matter what the arithmetic says.
How it works:
The question set changes with the framework, because each auditor looks for different evidence. SOC 2 Type 2, SOX 404 and a cybersecurity assessment each have their own ten questions. For SOX 404 and the cybersecurity set every question is treated as critical; for SOC 2, three of the ten are.
Each question offers four answers, ordered from no formal control to a control with a named owner and retained evidence, and they score zero, one, two and three in that order. The four options are written so the honest answer is obvious — the middle two describe what most companies actually do, rather than what they would like to say.
Scoring is deliberately strict about the second-best answer. Answering "partly there" scores two points and is counted as partial, not as in place, because a quarterly review that lives in a spreadsheet with informal sign-off is not evidence an auditor can sample. Counting it as complete is how a company with no retained proof ends up being told it is ready.
A zero on any question flagged critical raises a critical flag, and any critical flag caps both the readiness band and the recommended path at the second band. The score itself is still the plain arithmetic, so the number and the published method never disagree — it is the verdict that is held back, not the total.
Questions and answers:
Q: Is this an audit?
A: No. It is a preliminary readiness screen: ten questions answered by you, scored against a fixed rubric. It is not an audit, not an attestation, not an opinion, and not a prediction of whether you would pass one. Audits and attestations are performed by Alpha Secure LLP under separate engagement letters.
Q: Why did my score go down when I answered more honestly?
A: Because "partly there" is scored as partial rather than in place. A control with no named owner, no ticket and no retained export is real work, but it is not evidence an auditor can sample, and the scorecard is built to say so rather than to flatter the total.
Q: What is a critical flag?
A: A zero on a question the framework treats as critical — for SOC 2 that is access review, onboarding and evidence retention. Any critical flag holds the readiness band and the recommended path at the second band, however high the arithmetic score is, because those gaps are the ones that stop an audit rather than slow it.
Q: Do I have to give an email address to see my score?
A: No. The score, the band and the ranked gap list appear on the page as soon as you finish the questions. An email address is only needed if you want the report sent to you, and progress is kept in your own browser until then.
Q: Which frameworks can I score against?
A: SOC 2 Type 2, SOX 404, and a cybersecurity assessment. A SOC 1 set is registered but not offered: its questions are still a placeholder borrowed from the SOC 2 set, and showing it would mean scoring you against the wrong controls.