You are always inside an observation period. Evidence accumulates as you go, rather than being assembled ahead of an audit.
Some actions still require human intervention. Automated controls largely take care of themselves. Others need a person to convene a group, exercise judgment, or record a decision. How you prompt those is your call — in-app reminders, your own calendar, a ticket queue, or automated routing.
What your Type 2 audit covers
A Type 2 audit examines design and operating effectiveness throughout a defined window of time, usually called the observation period or audit period. It asks a second question: did those controls actually operate, and did they operate consistently enough across the window to conclude they are effective?
What your Type 1 audit covered
What your Type 1 audit covered
Your Type 1 audit examined the suitability of your control design as of a single specified date: whether your described system covered the criteria in scope, and whether those controls would achieve the objectives you committed to.
If a Type 2 is a film, a Type 1 is the photograph.
Time-specific control actions
The intervals below reflect the cadence in unaltered Thoropass policy templates.
Distribution matters as much as count. A quarterly action needs to have occurred roughly once per quarter across the period. Four instances performed in the final month do not satisfy audit requirements.
Quarterly
Quarterly
Risk committee meeting — a structured review of logged risks, measured and improved where needed as a team.
Access reviews — confirmation of permissions across in-scope systems, with anything flagged removed.
Vulnerability scanning and remediation — scanning on cadence, with findings closed inside your policy's timeframes.
Asset inventory — a current record of production systems and infrastructure.
Security incident documentation — a record of incidents from the quarter, including any remediation and channels used.
Annual
Annual
Vendor review for critical vendors — third-party risk assessed against current SOC 2 or ISO reports.
Policy review and republication — reviewed, republished, and acknowledged by employees.
Business continuity and disaster recovery testing — the plan exercised, with results recorded.
Incident response testing — a tabletop exercise against a realistic scenario.
Security awareness training — coverage across everyone in scope, including anyone who joined mid-period.
Performance reviews — completed for everyone in scope on the cadence your policy sets.
Penetration testing — must fall inside your period to be evidenced for it.
Ad-hoc events
Ad-hoc events
Auditors sample what changed during the observation period, not your entire company or its full history.
Background checks for people who joined during the period.
Policy acknowledgement within 30 days of joining.
Security training within 30 days of joining.
Access provisioning and termination across joiners, movers, and leavers.
How monitors relate to controls
How monitors relate to controls
A monitor supports a control; it is not the control. A healthy monitor demonstrates that a configuration held. That is sometimes most of what is needed, and sometimes one input alongside a record of human action.
An unhealthy monitor is not automatically a failed control, since an integration may have lost authorization or a resource may have been decommissioned. What the auditor looks for is a record that you investigated it.
When your security program should evolve
A program should change when the business does. If nothing material has changed, a steady program is a reasonable outcome.
Change is often prompted when a business experiences one or more of the following:
a new customer commitment
an action that keeps proving difficult to complete in prior audits
questions during vendor reviews that are hard to answer
How to assess risk and change in the business
How to assess risk and change in the business
Risk profile matters more than size. Two things drive it: what would be affected if something failed, and how likely that is. Both shift as you grow, independently of headcount.
Blast radius. How much of your customer base, data, or service a single failure would reach.
Likelihood. More systems, more people, and more change create more ways for something to go wrong.
Resourcing. Whether the people running the program have grown alongside what it now covers.
When the items above move materially, the control set is worth revisiting.
Adding a second framework
Adding a second framework
Many of the underlying disciplines are shared: access control, change management, risk assessment, vendor oversight, and more. Where two standards ask for the same thing, evidence can often be mapped across both rather than produced twice.
There will also be new systems and data subjects that come into scope for review. Thoropass team members can walk you through what that gap looks like to help make the best decision.
What to expect in a SOC 2 Type 2 audit
An audit team is assigned to your engagement for a defined window and rolls off at the end of it. Confirmed dates commit both sides: the auditors assigned to you, and the people on your side who own routing of evidence or attend the calls.
An audit module is activated for each observation period, because the evidence in it is specific to that window. Evidence from prior audits does not carry over to new audits.
Key milestones
Key milestones
Dates confirmed. Your audit module opens.
Documentation and policies linked.
Population evidence requests submitted, ahead of the population call.
Population call. A working session with your lead auditor to confirm completeness, interpret requests, and work through evidence where your business has unique constructs.
Sample selections issued. Drawn from your confirmed populations, reflecting the size and risk of each, and shared in your audit module.
Walkthrough call. Your lead auditor reviews what you have submitted and asks about anything that looks incomplete. A live working session, best attended by the people who perform the controls.
Remaining evidence due. Sample-based requests, plus anything surfaced during the walkthrough.
Testing, quality review, and iteration. Questions come back to you through the platform. Then a draft report, your sign-off, and the final report.
A missed deadline does not move the audit by the length of the delay. Because the assigned window is fixed and other engagements sit around it, a short slip can require rescheduling and push your report considerably further out.
How evidence submission is sequenced
How evidence submission is sequenced
Evidence falls into categories, and each becomes eligible at a different point in the period.
Evidence Category | Timing |
Policies | At the start of the review period |
Operational | At the start of the review period |
Configurations | 1–3 months before end of review period |
Populations | After 80% of review period has passed |
Samples | After populations have been uploaded and samples selected |
Each request carries an evidence eligibility date, the earliest point you can begin attaching evidence to it. Submitting late compresses the time available for review.
How population and sample requests differ
How population and sample requests differ
A population request is not a single artifact. It has two parts: the query or criteria used to generate it, and the results that query returned.
Two constraints shape the timing of these requests:
Some requests are time-gated. This ensures evidence is pulled with sufficient data across the observation period, so that an early submission does not affect the integrity of the review.
Sample selections are sequential and cannot be issued until the population stage is complete, so that the samples drawn are relevant to what the population review surfaced.
Key considerations for a smoother audit
These are the areas that most often determine how smoothly an audit runs. Any question here you cannot answer is worth attention before your next period opens.
Scope
Scope
What systems are in scope, and when did we last confirm that list against reality rather than documentation?
Has anything entered our environment this year that processes customer data and is not in our vendor inventory?
Have we changed regions, added a production environment, or acquired a team since the last period closed?
Who would notice if any of the above changed, and how would it reach us?
Ownership
Ownership
For every manual action, can we name the person who performs it today?
Which have exactly one person capable of performing them?
Has anyone who owned one left or changed roles in the last twelve months, and did it move with the role?
Intervals
Intervals
Does every recurring action have a named owner and a prompt that does not rely on someone remembering?
Looking back at last period, were quarterly actions actually distributed across quarters?
Does the upcoming period contain a full cycle of annual actions, including the penetration test?
Does the next period begin where the last ended?
How long does one instance actually take, multiplied by its frequency? A quarterly action costing a day of coordination is four days a year of someone's time.
Would we still do this if it were not required? If clearly not, the interval may be wrong, or the action may be worth automating.
Policy alignment
Policy alignment
When did we last read our policies end to end?
Is there anything in them we are not doing, or doing differently than described?
Are there remediation timeframes our engineering process cannot realistically meet?
Have we improved a practice without updating the policy describing it?
Evidence
Evidence
Does our evidence show an action was performed, or only that a capability exists?
Is it dated, attributable, and generated at the time rather than assembled afterward?
For actions with follow-up, can we show the follow-up closed?
Could we produce a complete population, and explain how we know nothing is missing?
Would the person who performs a control describe it the way our documentation does?
Who to ask, and what they can help with
You are not expected to work this out alone. Some answers are available in product at any time, and the people working alongside your program can help with the rest.
Help Center and AI assistant
Help Center and AI assistant
Step-by-step instructions for completing actions in the platform.
What a given screen, field, or request is asking for.
Definitions and terminology used across the audit process.
Customer Success Manager at Thoropass
Customer Success Manager at Thoropass
Industry perspective and considerations for implementing monitors that support control enforcement.
Platform navigation, product feedback, and workflow improvements.
Whether a change in your business prompts a closer look at scope.
These are observations drawn from working across many compliance programs, offered as perspective rather than as the only way to approach something. The decision stays with you.
InfoSec team or your auditor
InfoSec team or your auditor
Clarification on what a specific evidence request is asking for.
The tests and criteria used to evaluate whether a control is sufficient.
Requested updates to draft or final audit reporting documentation.
Changes to system names, legal entity names, or other DBA updates that need to be reflected.
While the period is open, you can still act on the answer and correspond directly with the auditor in the comments section of the audit module request.
What your auditor will not do is tell you what to build. An assurance provider cannot design the thing it later evaluates. A conclusion is only worth something to the client or prospect reading your audit report if it was reached independently.
Compliance program manager
Compliance program manager
This role is managed by your organization — an internal team member, a virtual CISO, or an external partner. However it is structured, the items below are relevant to whoever holds it.
Who owns each control.
What intervals your team can sustain — committee stand-ups, policy commitments, and the charters that define them.
What methods and processes support each control within your security program.
Where documentation lives, and what keeps it current over time.
Documentation and evidence may live in Thoropass or in your own knowledge base and systems, and neither is wrong. What stays with you is how the program matures, and where you choose to host and route evidence and monitors.
Frequently asked questions
How does a Type 1 relate to the Type 2 that follows it?
How does a Type 1 relate to the Type 2 that follows it?
They are separate engagements producing separate reports. Because evidence that a control operated has to originate inside the period being tested, completing a Type 1 does not reduce the evidence your Type 2 will require. The two are sequential rather than cumulative.
How long should our observation period be?
How long should our observation period be?
Six months is a common starting point for a first Type 2, because it contains two full cycles of any quarterly action your policies commit you to.
Twelve months is the steady state most organizations settle into. It lines up with annual vendor reviews and gives broader coverage, with each quarterly action measured four times across the year.
What does a longer observation period change?
What does a longer observation period change?
It covers a broader span, and every time-sensitive control action inside it has to occur and be evidenced across that full span.
If your policy sets a quarterly risk committee, a rolling twelve month period means four dated occurrences with auditable evidence linked for review, rather than two across six months.
Does a gap between our report periods matter?
Does a gap between our report periods matter?
Buyers reviewing vendors look at whether coverage is continuous. A bridge letter can be used to address the interval between one period ending and the next beginning. It is written and signed by your management rather than your auditor, so it carries your credibility rather than theirs. Contiguous periods remain the stronger position.
What happens if we missed a control instance during the period?
What happens if we missed a control instance during the period?
It may be described as a deviation in the report, often alongside your explanation of cause and remediation. One you identified and addressed reads very differently than one your auditor discovered. Whether any affect the opinion is a judgment about severity and pervasiveness.
Can we change a policy interval between audits?
Can we change a policy interval between audits?
Yes, as a governed change with review, approval, a recorded date, and a rationale. Expect the period to be tested against whichever policy was in force at each point in time.
Our team has grown substantially. What should we revisit?
Our team has grown substantially. What should we revisit?
System and vendor inventories, because growth introduces both.
Control ownership, because roles have shifted.
Training and acknowledgement coverage, because new joiners are the most common population gap.
Access review scope, because new systems arrive faster than review lists get updated.
Do we need a Type 2 audit report every year?
Do we need a Type 2 audit report every year?
No rule requires it, but buyer expectations effectively do. Most customers want a report covering a period that ended within the last twelve months. It is a customer commitment rather than a compliance requirement.
Our dashboard is green. Is that enough?
Our dashboard is green. Is that enough?
It is a useful signal, and not the same thing as assurance. A dashboard reflects what has been captured and configured. It cannot tell you whether your scope still matches your environment, or whether an interval you committed to is sustainable.
Related how-to articles
Audit documents for SOC 2 and SOC 1 — what your auditor asks for, and why.
SOC 2 to unified control map — how criteria map to the controls you maintain.
SOC 2 Tuesdays recordings — recorded sessions on specific topics.
