Between audits, SOC 2 monitoring means checking that each control keeps working and writing down what you found. The AICPA criteria expect a mix of ongoing and separate evaluations (CC4.1) and timely handling of deficiencies (CC4.2). In practice: automated checks for drift, a weekly human review, a monthly exceptions log and a quarterly deeper look.
Why do controls drift?
Nobody breaks a control on purpose. A new hire is added to an admin group and never reviewed. An engineer disables a check to unblock a deploy and forgets to turn it back on. A new cloud account appears outside your logging setup. Each is small. Together they are what Type 2 auditors find when they sample across a period.
A Type 2 report covers a period and includes tests of operating effectiveness. That means monitoring is not a nice to have. Controls must work on the days nobody is looking, and your evidence must show it.
What do CC4.1 and CC4.2 say about monitoring?
CC4.1 asks the entity to select, develop and perform ongoing and or separate evaluations to ascertain whether components of internal control are present and functioning. The AICPA points of focus describe a balance of ongoing and separate evaluations, a baseline understanding of the control system, evaluators with enough knowledge, integration with business processes and scope and frequency that vary with risk.
CC4.2 covers evaluating and communicating deficiencies to those responsible for corrective action, including senior management and the board, in a timely way.
CC7.1 and CC7.2 add the technical side: detection and monitoring procedures for configuration changes and new vulnerabilities, and monitoring of system components for anomalies.
Read together, they ask for two things you can show an auditor: checks that run, and a trail proving someone acted on what they found.
What should you watch, and how often?
Think in layers.
Daily or continuous, automated. Cloud configuration against your baseline (encryption, public access, logging enabled), identity provider settings (multi factor authentication enforced), endpoint protection status, vulnerability scan results, backup job success and alerts from your monitoring stack. Route failures into tickets automatically, so each one has an owner and a close date.
Weekly, human. A short review of open alerts, expired exceptions, new vendor sign ups and access changes. Fifteen minutes with a checklist beats an hour with none.
Monthly. Review the exceptions log, vulnerability aging against your policy deadlines, joiners and leavers against access, and any change management samples.
Quarterly. Access reviews for critical systems, a vendor check, a restore test or similar operational test, and a review of how many alerts were real.
Annually. Risk assessment, policy review, training cycle and incident response exercise.
Match frequency to risk, as the points of focus suggest. A production database deserves tighter checks than a design tool.
How do you record monitoring so an auditor can use it?
A check that ran without a record is, to an auditor, a check that did not run. Keep:
- The check definition: what it tests, how often, who owns it.
- Output with timestamps, retained for the audit period.
- A ticket for every failure showing owner, action, closure date and closure evidence.
- An exceptions log: what failed, why, how long it ran, what you changed.
- Meeting notes from weekly and monthly reviews, even short ones.
Consistent naming and one shared location save audit week.
What mistakes cause pain later?
- Alerts with no owner, so failures sit for weeks.
- Monitoring that checks the existence of a setting once, not the continued state.
- Silent exceptions: a control off for six weeks with no ticket.
- Checks that cover production but not the new cloud account created in month three.
- Evidence captured only at audit time.
- Treating a passing dashboard as monitoring. Someone must look at it and act.
What to do
- List your controls and mark which can be tested automatically.
- Automate the top ten by risk first: identity, encryption, logging, backups, vulnerabilities.
- Send every failed check to a ticket queue with a named owner.
- Schedule a weekly fifteen minute review and a monthly exceptions review.
- Keep an exceptions log and review it monthly.
- Add new accounts and tools to monitoring scope at creation time.
- Every quarter, sample your own evidence as an auditor would and fix gaps.
Quick check
Does SOC 2 require continuous monitoring tooling?
The criteria require evaluations that show controls are present and functioning, with a balance of ongoing and separate checks. Tooling is one way to do ongoing checks; the criteria do not name a product.
What happens if a control fails mid period?
Document it, fix it, and record the cause and the date. The auditor tests operating effectiveness across the period, so a timely, documented response is better than silence.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022): CC4.1, CC4.2, CC7.1, CC7.2 and the Type 1 and Type 2 definitions.
How Safeguard helps automate this
Monitoring between audits is what Safeguard's compliance suite is built for. It covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code rather than screenshots and the checks keep running between audits, freeing the team for other work. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability, not only from policies. The remediation agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and set the approval level. Your independent auditor still issues the report. See the mapping below or book a call.
Explore the framework mapping demo.
Last reviewed: 18 October 2026.
