Does SOC 2 require a quarterly security report?

The criteria do not name a report or a frequency. CC2.2 and CC2.3 ask whether security information reaches the people who need it, including management, and CC4.2 asks whether deficiencies are communicated to those who can fix them. Most auditors test this against your own policy. The Information Security Policy in the Policyseed set requires a written status report to management at least quarterly, so the auditor will ask for the reports from the audit period and the record that management received them.

Who receives the report at a small company?

Whoever your policies call Executive Management: at a company of a few people that is usually the founders or the CEO, and the board if you have one. The report still needs a date, a recipient and an acknowledgment. A signed page or a line in the meeting minutes is enough; a report nobody can show was received does not help.

Why do some metrics say [Fill in: target]?

Every target comes from a sentence in your policies. Where the policy requires something but sets no number, such as the count of incidents, the number of open exceptions or the availability objective, the tracker leaves the target for management to set. Until it is set, the status column reads Set a target instead of guessing.

What if a metric misses its target?

Report it. A missed target with its cause, an action, an owner and a due date is exactly the deficiency communication CC4.2 looks for. Auditors find a quarter of honest Not met rows more credible than four quarters where everything is green and the underlying records disagree.

Does a Met status mean the control works?

No. Met only means the value someone entered meets the target. The auditor tests the evidence behind each number: the access review sign-offs, the vulnerability register, the restore test records. Keep that evidence where the tracker's notes column says, for the same quarter as the report.

Where do the files go in the Audit Kit?

The Audit Kit puts the report template and the tracker in its governance folder, next to the policy approval minutes and the policy register, built from your answers and your tailored policies.

Quarterly security report and metrics tracker for SOC 2

Updated 24 October 2026

Your policies say management receives a written security report every quarter. This page derives the metrics for that report from what your 22 policies actually require: access reviews, leavers, vulnerability deadlines, training, incidents, restore tests, vendor reviews, exceptions and risks, each with the target its policy statement sets. Download a Word report template with a management sign-off section and an Excel tracker with four quarters of status formulas. Built in your browser: no signup, nothing uploaded.

Security metrics: Northwind Cloud Inc

Each metric comes from a statement in the policies, with the target that statement sets. Built in your browser; nothing is uploaded.

No generator answers found in this browser, so the metrics come from the sample company, Northwind Cloud Inc. Answer the 23 generator questions to derive them from your own policies.

Metrics: 21
Policies cited: 12
Targets to set: 3

Tailored from: Headcount 11-50 · Identity provider Okta · Source control GitHub · Hosting AWS and Vercel · Device management Kandji · Trust Services Criteria in scope Security and Availability

Access

ACC-01Access reviews completed on schedule
Target: 100% of systems in the quarterly scope reviewed and signed off in the quarter
P03 4.10 Access Control Policy · Dana Whitfield, CTO (Security Owner) · Measured: Quarterly (P03 4.10)
What the policy says and where the number comes from
“Access is reviewed at least quarterly for production, source code, identity administration and any system holding Restricted data, and at each annual review for all other systems.”
How to measure: Systems in the quarterly scope (production, source code, identity administration and any system holding Restricted data) with a signed-off review this quarter, divided by all systems in that scope.
Evidence: Signed-off review for each system: user and role exports from Okta, the identity services of AWS and Vercel, GitHub, Supabase, Stripe, Datadog and Slack and production databases, reconciled against the HR roster.
ACC-02Leavers with access removed within the policy deadline
Target: 100% of leavers: identity provider account disabled before the end of the last working day; all other access removed within one business day
P03 4.11 Access Control Policy · Dana Whitfield, CTO (Security Owner) · Measured: Every departure
What the policy says and where the number comes from
“When a person leaves Northwind Cloud Inc, their identity provider account is disabled and their sessions revoked before the end of the last working day, and all other access is removed within one business day.”
How to measure: Leavers this quarter whose access was removed within both deadlines, divided by all leavers this quarter.
Evidence: Offboarding checklists or tickets, with the time each account was disabled in Okta and the other systems, compared with the last working day in the HR record.
Leave the value blank in a quarter with none; a blank value has no status.
ACC-03Role changes with access adjusted within the policy deadline
Target: 100% of role changes: access the new role does not need removed within five business days
P03 4.11 Access Control Policy · Dana Whitfield, CTO (Security Owner) · Measured: Every role change
What the policy says and where the number comes from
“When a person changes role, access the new role does not require is removed within five business days.”
How to measure: Role changes this quarter where access the new role does not need was removed within the deadline, divided by all role changes this quarter.
Evidence: Role-change access review tickets, with the date of the change from the HR record and the date access was removed.
Leave the value blank in a quarter with none; a blank value has no status.
ACC-04Workforce accounts with multi-factor authentication
Target: 100% of workforce accounts
P04 4.2 Authentication and Password Policy · Dana Whitfield, CTO (Security Owner) · Measured: Monthly (P04 5.2)
What the policy says and where the number comes from
“Multi-factor authentication is mandatory for every workforce account at Northwind Cloud Inc, without exception for seniority.”
How to measure: Workforce accounts with multi-factor authentication enrolled at the end of the quarter, divided by all workforce accounts.
Evidence: Multi-factor enrollment export from Okta, the identity services of AWS and Vercel and GitHub.

Change management

CHG-01Sampled production changes with independent approval
Target: 100% of sampled changes with independent approval, passing checks and a deployment record
P09 5.8 Change Management Policy · Dana Whitfield, CTO (Security Owner) · Measured: Monthly (P09 5.8)
What the policy says and where the number comes from
“Monthly change review. The Security Owner samples at least ten percent of production changes and no fewer than five, verifies independent approval, passing checks and a deployment record for each, confirms branch protection settings in GitHub remain as required, investigates any bypass or emergency change, and summarizes the results to Executive Management.”
How to measure: Changes in the quarter's monthly samples with all three records, divided by all sampled changes.
Evidence: Monthly change review records: the sampled pull or merge requests in GitHub, their check results from GitHub Actions and the deployment records.

Vulnerabilities

VUL-01Critical vulnerabilities past the remediation deadline
Target: 0 Critical findings open more than 7 days after detection
P11 4.3 Vulnerability and Patch Management Policy · Engineering Lead · Measured: Monthly (P11 4.12)
What the policy says and where the number comes from
“Findings are remediated within timelines measured from detection: Critical within 7 days, High within 30 days, Medium within 90 days, and Low within 180 days or at the next scheduled maintenance, whichever is sooner.”
How to measure: Critical findings in the vulnerability register still open past their due date at the end of the quarter.
Evidence: Vulnerability register: asset, severity, source, detection date, due date, status and closure evidence.
VUL-02High vulnerabilities past the remediation deadline
Target: 0 High findings open more than 30 days after detection
P11 4.3 Vulnerability and Patch Management Policy · Engineering Lead · Measured: Monthly (P11 4.12)
What the policy says and where the number comes from
“Findings are remediated within timelines measured from detection: Critical within 7 days, High within 30 days, Medium within 90 days, and Low within 180 days or at the next scheduled maintenance, whichever is sooner.”
How to measure: High findings in the vulnerability register still open past their due date at the end of the quarter.
Evidence: Vulnerability register: asset, severity, source, detection date, due date, status and closure evidence.
VUL-03Medium vulnerabilities past the remediation deadline
Target: 0 Medium findings open more than 90 days after detection
P11 4.3 Vulnerability and Patch Management Policy · Engineering Lead · Measured: Monthly (P11 4.12)
What the policy says and where the number comes from
“Findings are remediated within timelines measured from detection: Critical within 7 days, High within 30 days, Medium within 90 days, and Low within 180 days or at the next scheduled maintenance, whichever is sooner.”
How to measure: Medium findings in the vulnerability register still open past their due date at the end of the quarter.
Evidence: Vulnerability register: asset, severity, source, detection date, due date, status and closure evidence.

Endpoints

END-01Devices out of compliance for more than the policy allows
Target: 0 devices out of compliance for more than seven days
P19 5.3 Endpoint and Workstation Security Policy · IT/Operations Lead · Measured: Monthly (P19 5.3)
What the policy says and where the number comes from
“Each month the Security Owner reviews the Kandji compliance report, and any device out of compliance for more than seven days is blocked from company applications until remediated.”
How to measure: Devices in the compliance report that had been out of compliance for longer than the policy allows and were not blocked, at the end of the quarter.
Evidence: Monthly compliance report from Kandji and the list of blocked devices.

People

PPL-01Security awareness training completed on time
Target: 100% of personnel trained within 30 days of starting and at least every 12 months
P18 4.4 Human Resources Security Policy · People/HR Lead · Measured: At hire and annually; reported quarterly
What the policy says and where the number comes from
“All personnel complete security awareness training within 30 days of starting and at least every 12 months thereafter.”
How to measure: Personnel whose awareness training is within its deadline at the end of the quarter, divided by all personnel on the HR roster.
Evidence: Training completion records from the training platform or People Operations, compared with the HR roster.
PPL-02Policy acknowledgments current
Target: 100% of personnel acknowledged within five business days of starting and within 30 days of each revision
P18 5.3 Human Resources Security Policy · People/HR Lead · Measured: At hire and on every revision
What the policy says and where the number comes from
“All personnel acknowledge the Information Security Policy, the Acceptable Use Policy and this policy within five business days of starting and within 30 days of each revision.”
How to measure: Personnel with a current acknowledgment of the required policies, divided by all personnel on the HR roster.
Evidence: Signed acknowledgments stored with the personnel records, compared with the HR roster and the policy versions in force.

Incidents

INC-01SEV1 and SEV2 incidents in the quarter
Target: set by management; the policy states no number
P13 5.9 Incident Response Policy · Dana Whitfield, CTO (Security Owner) · Measured: Every incident
What the policy says and where the number comes from
“Each quarter the Security Owner reports to Executive Management the number of incidents by severity, mean time to acknowledge, contain and resolve, notifications made, overdue corrective actions and trends.”
How to measure: Incidents opened this quarter at SEV1 or SEV2. The report breaks the count down by severity, with SEV3 and SEV4.
Evidence: Incident log (INC-YYYY-NNN records), with the alerts from Datadog that opened them.
The policy sets no target for the number of incidents. Set one only if management wants a threshold that triggers a discussion.
INC-02SEV1 and SEV2 incidents contained within the policy target
Target: 100% of SEV1 and SEV2 incidents contained within the target for their severity (SEV1: 1 hour; SEV2: 4 hours)
P13 section 2 Incident Response Policy · Dana Whitfield, CTO (Security Owner) · Measured: Every SEV1 and SEV2 incident
What the policy says and where the number comes from
“SEV1 - Critical: Acknowledge in 15 minutes; Incident Commander in 30 minutes; containment under way in 1 hour; updates hourly | SEV2 - High: Acknowledge in 30 minutes; Incident Commander in 1 hour; containment in 4 hours; updates every 4 hours”
How to measure: SEV1 and SEV2 incidents this quarter where containment started within the target for their severity, divided by all SEV1 and SEV2 incidents this quarter.
Evidence: Incident records with timestamps for detection, acknowledgment, containment and closure.
Leave the value blank in a quarter with none; a blank value has no status.
INC-03Post-incident reviews held on time
Target: 100% of closed SEV1 and SEV2 incidents reviewed within five business days of closure
P13 4.11 Incident Response Policy · Dana Whitfield, CTO (Security Owner) · Measured: Every SEV1 and SEV2 incident
What the policy says and where the number comes from
“Every SEV1 and SEV2 incident receives a blameless post-incident review within five business days of closure that produces a root cause, impact statement and corrective actions with owners and due dates, tracked to closure and reported to Executive Management.”
How to measure: SEV1 and SEV2 incidents closed this quarter with a post-incident review within the deadline, divided by all SEV1 and SEV2 incidents closed this quarter.
Evidence: Post-incident review documents with their dates, linked from the incident records.
Leave the value blank in a quarter with none; a blank value has no status.

Backups

BCK-01Backup restore tests performed
Target: At least 1 restore test of Tier 1 data in the quarter
P15 4.8 Backup and Recovery Policy · Engineering Lead · Measured: Quarterly (P15 4.8)
What the policy says and where the number comes from
“Restores are tested at least quarterly for a sample of Tier 1 databases and storage, and at least annually for a full Tier 1 environment as part of the disaster recovery test.”
How to measure: Restore tests of Tier 1 databases or storage performed this quarter with a complete test record.
Evidence: Restore test records: what was restored from AWS Backup, the backup age, the elapsed time, the verification performed and any defects.

Vendors

VEN-01Vendor reviews overdue
Target: 0 Tier 1 or Tier 2 vendors more than twelve months past their last review
P16 5.5 Vendor and Third-Party Risk Management Policy · Dana Whitfield, CTO (Security Owner) · Measured: Annually per vendor; overdue count reported quarterly
What the policy says and where the number comes from
“The Security Owner reviews every Tier 1 and Tier 2 vendor within twelve months of its last review, obtaining the updated assurance report, checking incident history and sub-processor changes, re-confirming tier and data with the business owner, recording outcomes and actions, and summarizing for Executive Management the vendors whose risk has increased.”
How to measure: Tier 1 and Tier 2 vendors whose last review is older than the policy allows at the end of the quarter. Report the vendors due next quarter alongside.
Evidence: Vendor inventory with tier and last review date, and the review records (for example Supabase, Stripe, Datadog and Slack).

Exceptions

EXC-01Open policy exceptions
Target: set by management; the policy states no number
P01 5.6 Information Security Policy · Dana Whitfield, CTO (Security Owner) · Measured: On every request; reported quarterly
What the policy says and where the number comes from
“Approved exceptions are logged in the exception register and reviewed at each annual review.”
How to measure: Approved exceptions in the exception register that have not expired or been closed at the end of the quarter.
Evidence: Exception register: statement affected, justification, compensating controls, risk owner, approver and expiry date.
The policy limits how long an exception lasts, not how many may be open. Set a threshold here if management wants one.
EXC-02Exceptions past their expiry date
Target: 0 exceptions still in use after their expiry date (each expires no more than twelve months after approval)
P01 5.6 Information Security Policy · Dana Whitfield, CTO (Security Owner) · Measured: Quarterly
What the policy says and where the number comes from
“Requests are submitted in writing to the Security Owner stating the statement affected, the justification, compensating controls, the risk owner and an expiry date no more than twelve months out.”
How to measure: Exceptions whose expiry date has passed without renewal or closure, at the end of the quarter.
Evidence: Exception register expiry dates, compared with the date of the report.

Risk

RSK-01Critical risks without an active treatment plan
Target: 0 Critical risks without an active treatment plan
P17 4.6 Risk Assessment and Management Policy · Dana Whitfield, CTO (Security Owner) · Measured: Quarterly
What the policy says and where the number comes from
“Northwind Cloud Inc's risk appetite, approved by Executive Management, is that no Critical risk is carried without an active treatment plan, no risk of exposing customer data or PII data is accepted at High or Critical, and risks to customer availability commitments are treated before risks affecting only internal convenience.”
How to measure: Risks rated Critical in the risk register with no treatment plan in progress at the end of the quarter.
Evidence: Risk register: rating, treatment, actions with owners and due dates.
RSK-02Customer data risks accepted at High or Critical
Target: 0 risks of exposing customer data accepted at High or Critical
P17 4.6 Risk Assessment and Management Policy · Dana Whitfield, CTO (Security Owner) · Measured: Quarterly
What the policy says and where the number comes from
“Northwind Cloud Inc's risk appetite, approved by Executive Management, is that no Critical risk is carried without an active treatment plan, no risk of exposing customer data or PII data is accepted at High or Critical, and risks to customer availability commitments are treated before risks affecting only internal convenience.”
How to measure: Risks of exposing customer data recorded as accepted while rated High or Critical, at the end of the quarter.
Evidence: Risk register: acceptance decisions with approver, rating and expiry.

Availability

AVL-01Availability against the service level objective
Target: set by management; the policy states no number
P12 4.9 Logging and Monitoring Policy · Engineering Lead · Measured: Monthly (P12 5.9)
What the policy says and where the number comes from
“Because Availability is within scope, Northwind Cloud Inc defines service level objectives for availability and latency, monitors and alerts against them, and maintains a customer-facing status page updated within 30 minutes of a confirmed customer-impacting outage.”
How to measure: Measured availability of the product for the quarter, as a percentage, from the uptime checks.
Evidence: Uptime and service level objective reports from Datadog, and the status page history.
The policy requires a service level objective but does not set its value. Enter the objective you publish or commit to customers as the target.

What auditors look for

Three SOC 2 criteria meet in this report. CC2.2 asks whether information about security responsibilities and performance reaches people inside the company, management included. CC2.3 covers communication with outside parties such as customers and vendors, and the report records the notices sent after incidents. CC4.2 asks whether the deficiencies that monitoring finds are evaluated and communicated to the people responsible for fixing them, including senior management.

In practice the auditor asks for:

The reports from the audit period, at the frequency your policy states. A Type II period of six to twelve months means two to four quarterly reports.
Proof they reached management. A signature, an acknowledgment, or meeting minutes that record the report and the decisions taken on it.
Deficiencies with follow-up. Metrics that missed their target, with a cause, an action, an owner and a date, and the same item closed or carried forward in the next report.
Numbers that match the records. The auditor may pick a metric and trace it to the access review sign-off, the vulnerability register or the incident log for the same quarter.

The sample company’s policy sets the requirement this way (P01 Information Security Policy, 5.4): “Management reporting. The Security Owner delivers a written status report to Executive Management at least quarterly covering open risks, incidents, vulnerability and patch status, access review results, vendor reviews and progress against objectives. Decisions are minuted.”

How the metrics are chosen

A metric is included only when a policy statement requires the thing it measures, and its target is read from that statement’s text. Change the deadline in the policy and the target changes with it. Answers to the generator change the set too: a team of 1-10 people gets the incident containment targets its own Incident Response Policy sets for a team without a staffed rotation; a company without device management gets the quarterly endpoint attestation its Endpoint and Workstation Security Policy requires instead of a device compliance count; the availability metric appears only when Availability is in scope; and the evidence sources name your identity provider, source control, hosting and tools.

Metric	Target	From
ACC-02 Leavers with access removed within the policy deadline	100% of leavers: identity provider account disabled before the end of the last working day; all other access removed within one business day	P03 4.11
VUL-01 Critical vulnerabilities past the remediation deadline	0 Critical findings open more than 7 days after detection	P11 4.3
INC-02 SEV1 and SEV2 incidents contained within the policy target	100% of SEV1 and SEV2 incidents contained within the target for their severity (SEV1: 1 hour; SEV2: 4 hours)	P13 section 2
BCK-01 Backup restore tests performed	At least 1 restore test of Tier 1 data in the quarter	P15 4.8
EXC-01 Open policy exceptions	Set by management (the policy states no number)	P01 5.6

The examples are from the sample company’s policies. The list above and the downloads use your own answers when this browser has them.

What is in the download

Report template (Word): summary, the metrics table with each target, metrics not met with cause and action, where each metric comes from, incidents by severity with the policy’s response targets, new and re-rated risks, the risk appetite, significant changes, open exceptions, remediation of findings, decisions requested and a management acknowledgment with signature lines. Every figure is a [Fill in] placeholder.
Metrics tracker (Excel): a Metrics sheet with each definition, the policy statement quoted with its number, target, evidence source, owner and frequency; a Quarterly data sheet with a value and a status formula for each of four quarters, the latest value and totals; and instructions.

Running the quarterly cycle

In the first weeks after quarter end, each owner enters their values in the tracker and files the evidence.
The Security Owner copies the values into the report, explains each Not met and drafts the decisions requested.
Management reads the report at the security meeting, takes the decisions and signs the acknowledgment.
Actions go to the risk register or the remediation table, and the next report starts from them.

Related records: the risk register, the access review, the vendor review records and the incident response tabletop all produce numbers this report uses. The Audit Kit includes the report template and the tracker in its governance folder, built from your answers and your tailored policies.

Frequently asked questions

Does SOC 2 require a quarterly security report?: The criteria do not name a report or a frequency. CC2.2 and CC2.3 ask whether security information reaches the people who need it, including management, and CC4.2 asks whether deficiencies are communicated to those who can fix them. Most auditors test this against your own policy. The Information Security Policy in the Policyseed set requires a written status report to management at least quarterly, so the auditor will ask for the reports from the audit period and the record that management received them.
Who receives the report at a small company?: Whoever your policies call Executive Management: at a company of a few people that is usually the founders or the CEO, and the board if you have one. The report still needs a date, a recipient and an acknowledgment. A signed page or a line in the meeting minutes is enough; a report nobody can show was received does not help.
Why do some metrics say [Fill in: target]?: Every target comes from a sentence in your policies. Where the policy requires something but sets no number, such as the count of incidents, the number of open exceptions or the availability objective, the tracker leaves the target for management to set. Until it is set, the status column reads Set a target instead of guessing.
What if a metric misses its target?: Report it. A missed target with its cause, an action, an owner and a due date is exactly the deficiency communication CC4.2 looks for. Auditors find a quarter of honest Not met rows more credible than four quarters where everything is green and the underlying records disagree.
Does a Met status mean the control works?: No. Met only means the value someone entered meets the target. The auditor tests the evidence behind each number: the access review sign-offs, the vulnerability register, the restore test records. Keep that evidence where the tracker's notes column says, for the same quarter as the report.
Where do the files go in the Audit Kit?: The Audit Kit puts the report template and the tracker in its governance folder, next to the policy approval minutes and the policy register, built from your answers and your tailored policies.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.