SOC 2 Observation Period: Start When Evidence Is Ready

A SOC 2 observation period should start when the scoped controls are operating and the team can preserve reliable evidence, not when someone adds dates to a plan. Management can track a candidate period first. Keep it separate from the formal Type 2 period agreed with the CPA firm, and do not backdate either one to cover work that was not ready.

TL;DR

• Confirm that the customer needs Type 2 and what coverage it will accept.
• Ask a qualified CPA firm to review the proposed scope and period.
• Start management’s candidate period only after the evidence-ready checks pass.
• Test every source export before relying on it for period-wide evidence.
• Run scheduled and event work inside its allowed window.
• Record control, source, scope, and owner changes with their effective dates.
• Preserve complete populations when the CPA firm may sample activity.
• Check period health while there is still time to fix a gap.

What is a SOC 2 observation period?

A SOC 2 observation period is the date range covered by a Type 2 examination. Management operates the scoped controls and keeps dated records across that range. The CPA firm performs its procedures, evaluates exceptions, and issues the report.

The AICPA’s authoritative SOC 2 guide focuses on a service organization’s system and controls relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy. It covers the evaluation of control design and effectiveness. The period matters because a Type 2 engagement addresses operating effectiveness, while Type 1 uses a specified date. The SOC 2 Type 1 vs Type 2 guide explains that choice in detail.

Teams use several names for this date range, including observation period, audit period, report period, and evidence period. Those labels can hide an important distinction. Management may begin a candidate period for planning and collection. The formal period belongs to the real engagement after the CPA firm agrees to the dates.

How long should a SOC 2 observation period be?

Do not copy a period length from a search result and treat it as an audit rule. Ask the report user what it will accept, then plan the period with the CPA firm.

The decision should account for:

Input	Question to answer
Report user	Does the customer require a minimum report period, recent end date, or bridge coverage?
Control cadence	Will each scheduled control have expected occurrences inside the proposed range?
Existing history	Can management support control operation from the first day without reconstruction?
Source retention	Will authoritative systems retain the needed events, reports, and populations?
Scope changes	Will a planned launch, migration, vendor change, or acquisition alter the system?
Team capacity	Can owners perform, review, and preserve each activity on time?
CPA plan	Can the firm accept the scope, dates, fieldwork schedule, and available evidence?
Renewal plan	Will the end date support the next report cycle and customer needs?

A shorter period can still contain a low-frequency control that has only one expected occurrence. A longer period can still fail if evidence sources lose history or owners miss scheduled work. Calendar length alone does not make a period supportable.

Use the SOC 2 timeline for startups to map readiness, operation, fieldwork, and report review as separate dependencies.

Keep the candidate period separate from the formal period

Use two records because they answer different questions:

Record	Owner	Purpose
Management candidate period	Startup management	States when management believes reliable Type 2 collection can begin
Formal report period	Startup management and the engaged CPA firm	Records the exact coverage agreed for the examination

The dates may match, but do not assume they will. The CPA firm may request a different start, end, scope, or evidence plan after reviewing the engagement. Preserve both records when the dates differ so the planning history stays clear.

In FileGRC, the candidate range belongs on the Program. This non-valid excerpt shows only the period fields and omits required scope, control, owner, applicability, and risk-method details:

{
  "id": "program-soc-2",
  "type": "program",
  "title": "SOC 2 Program",
  "status": "active",
  "assuranceGoal": "soc-2-type-2",
  "candidateCoverage": {
    "kind": "range",
    "startsOn": "YYYY-MM-DD",
    "endsOn": "YYYY-MM-DD"
  }
}

The agreed coverage belongs on the Audit. This non-valid excerpt omits required engagement fields such as the Program, Framework, scope, owner, CPA firm, and fieldwork dates:

{
  "id": "audit-soc-2-type-2",
  "type": "audit",
  "title": "SOC 2 Type 2 Examination",
  "status": "in-progress",
  "auditKind": "soc-2-type-2",
  "coverage": {
    "kind": "range",
    "startsOn": "YYYY-MM-DD",
    "endsOn": "YYYY-MM-DD"
  }
}

Do not paste either excerpt into a workspace. Inspect the full Program mutation shape and scaffold a valid Audit instead:

npx filegrc list program --json
npx filegrc get PROGRAM_ID --mutation
npx filegrc scaffold audit --title "SOC 2 Type 2 Examination"

The dates are placeholders, not recommendations. Git commit times also do not set either period. Store the business dates explicitly.

Pass an evidence-ready gate before day one

Run a pre-period review against the exact service and controls. Start only when the facts support the proposed first day.

Scope and ownership

• The Program names the bounded Systems, selected criteria, Controls, and owners.
• Required roles have active, dated appointments that can cover the period.
• Material providers, components, commitments, and customer responsibilities are recorded.
• Planned scope changes have owners and dates.

Policies and controls

• Required Policies and governed Documents are approved, active, and effective.
• Each scoped Control is implemented with a real owner and procedure.
• Control start dates are on or before the planned period start.
• Recurring and event-driven work has clear triggers, allowed windows, and deadlines.

Evidence sources

• Every control family has an authoritative source with an access owner.
• Retrieval instructions name the report, query, filters, environment, timezone, and expected output.
• Retention covers the proposed range.
• A dry run proves the team can retrieve, fix, review, and protect the output.
• Split sources are recorded when one system does not contain the full population.

The SOC 2 evidence collection guide shows how to connect each control to its source, operating record, artifact, and review. FileGRC does not sign in to source systems or fetch their data.

Operate the controls throughout the period

Day one is a handoff from preparation to routine work. Owners still need to perform each control as designed and keep the result.

Scheduled work

Run access reviews, risk reviews, policy reviews, training, vendor reviews, tests, and other scheduled activities inside their approved windows. Keep the population, performer, reviewer, result, evidence, exceptions, and follow-up for each occurrence.

Event-driven work

Record hires, departures, access changes, releases, incidents, vendor changes, and other triggering events when they happen. Preserve the request, approval, execution, result, and source identifiers before the context disappears.

Continuous sources

Monitor source continuity, collection failures, retention, and access. A log stream or automated export still needs a defined control purpose, coverage, review, and exception path.

For sampled activity, preserve the complete management population before the CPA firm chooses samples. Record the source, query, filters, generation time, timezone, count, fixed export, and completeness checks. A zero count still needs a clear source and boundary.

Record changes instead of hiding them

The service will change during a real observation period. Record what changed, when it took effect, who approved it, which controls and sources it affected, and whether the change created a gap.

Review at least these changes:

• a control procedure, frequency, owner, or system changes;
• a Policy or governed Document changes after activation;
• an evidence source, report, filter, or retention setting changes;
• a material provider or component enters or leaves scope;
• a required role has a gap between appointments;
• a system migration changes the available history or identifiers;
• a control occurrence is missed, late, incomplete, or blocked.

Do not edit the current record to make the earlier state disappear. Keep the effective dates and history reviewable, record an exception when needed, and ask the CPA firm how the change affects its procedures or report language.

Check period health before fieldwork

A period-health check asks whether the planned range still has continuous support. It should surface work while management can respond, not wait for the CPA request list.

Check	Example warning	Management response
Git and source history	Available history starts after the proposed date	Identify authoritative earlier history or change the candidate start
Roles	A required appointment ends before the period ends	Record the real successor and effective date, then assess any gap
Policies and controls	A required item became effective after day one	Correct the proposed start or document the change and impact
Source coverage	A source is not valid for the full range	Repair the evidence path, record split coverage, or revise the plan
Due work	A scheduled occurrence is blocked or overdue	Complete the work honestly and record the exception and follow-up
Record changes	A control or source has several period revisions	Review effective dates, continuity, and any needed event or exception
Late evidence	The first record appears well after the source event	Preserve the reason and verify the original authoritative source

FileGRC can calculate these management checks from current JSON and Markdown records plus Git history:

npx filegrc program-readiness --summary --json
npx filegrc period-health --require-healthy --json
npx filegrc obligations --json
npx filegrc audit-readiness audit-id --json

Use period-health audit-id after the formal Audit has agreed coverage. Without an Audit ID, the command evaluates the Program’s candidate period. The command does not predict the CPA firm’s tests or decide whether evidence is sufficient.

Protect evidence while the period runs

Observation-period evidence may contain access lists, workforce data, incidents, vulnerabilities, customer facts, contracts, and system details. Decide the approved destination before collecting each source.

Do not put plaintext credentials, private keys, tokens, recovery codes, or personal data that may need erasure into Git. Keep prohibited or retention-sensitive material in an approved restricted system, then store a safe external reference and the metadata needed to review its source, scope, dates, collector, and status.

Use an approved encrypted channel for evidence the CPA firm requests. A clean internal period-health result does not mean the firm has accepted an item.

Run the observation period as files in Git

FileGRC is an open source, Git-native GRC workspace for SOC 2 work. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history.

FileGRC keeps management’s candidate period separate from the formal Audit, tracks recurring and event work, checks role and source continuity, and reports current period blockers. Source systems still operate controls and produce source evidence. The CPA firm still sets its procedures, selects samples, evaluates exceptions, and decides whether evidence is sufficient.

npx create-filegrc@latest company-grc
cd company-grc
npm run validate
npx filegrc program-path --next --json
npx filegrc period-health --require-healthy --json

Starter records are proposals, not compliance claims. Review them against how the company actually works before adopting them or starting a candidate period.