“Continuous compliance” is a term the SaaS GRC marketing industry has successfully mangled. In vendor copy it usually means “our platform runs some automated checks and our customers don’t have to think about compliance anymore.” In operational reality it means “the controls you certified against are running on a defined cadence, producing evidence on a defined cadence, and somebody is responsible for making sure both continue to happen.”
The first version is a marketing promise. The second version is what your auditor, your customer’s privacy team, and HHS OCR (if you’re HIPAA-bound) actually want to see. This article is about the second version — the operational calendar for post-certification compliance at a mid-sized SaaS company, covering SOC 2, ISO 27001, and adjacent framework obligations.
What continuous compliance actually means
Three things. First, the cadences you declared during certification continue on schedule. If your access review policy says quarterly, access reviews happen quarterly — not once a year because nobody rescheduled them after the initial audit. If your vulnerability scan policy says weekly, vulnerability scans happen weekly. The auditor reads the policy; the auditor expects the operation to match the policy.
Second, evidence of each control operation is produced, preserved, and retrievable. A control that ran but produced no evidence didn’t run, as far as your next audit is concerned. Continuous compliance is substantially an exercise in evidence management — designing evidence capture into the control itself, storing the evidence somewhere central, and having an inventory of what evidence exists for which control.
Third, findings from the ongoing operation feed a documented improvement cycle. Controls that fail get investigated. Investigations produce remediation. Remediation outcomes get documented. ISO 27001 requires this formally through the management review cycle. SOC 2 expects it implicitly through the annual report structure. HIPAA regulators look for it after any material incident.
The “continuous” in continuous compliance is the cadence, not the automation. Automation helps — sometimes substantially — but the underlying discipline is operational project management, not software.
The annual recurring cycle at a glance
A healthy annual compliance cycle at a mid-sized SaaS company running SOC 2 Type II plus ISO 27001 looks approximately like this:
Monthly: Access reviews (sampled), patching cadence, policy acknowledgements,
security metrics report, incident review, vendor inventory check
Quarterly: Full access reviews, vulnerability scans, segmentation validation (PCI),
vendor risk reassessment (high-tier), DR tabletop or test, evidence audit,
policy review (rotating)
Semi-annual: Pen test, business continuity test, DR full exercise, scope review
Annual: Internal audit, management review, risk assessment refresh, all-vendor
review, security awareness training, policy full refresh, audit fieldwork,
certification or surveillance eventThe shape: three overlapping rhythms — monthly operational work, quarterly reviews, and annual governance artefacts. The quarterly work is the backbone. Most compliance programme failures concentrate at the quarterly level: access reviews that slipped, vulnerability remediation that lapsed, vendor reassessments that didn’t happen.
Quarterly evidence collection cycle
Each quarter has roughly the same shape but different focus areas within it. The four-quarter cycle distributes annual work so no single quarter is unmanageable.
Q1 — Internal audit and risk refresh. The post-certification year’s heaviest quarter. Internal audit (ISO 27001) or equivalent self-review (SOC 2) covering a rotating subset of controls. Risk assessment refresh. Annual security awareness training refresh. All-vendor review (or kick-off if running full-year vendor refresh — see the vendor risk management programme). Policy reviews on a rotating cadence (typically 25% of policies per quarter, so the full suite gets reviewed annually).
Q2 — Penetration testing and technical validation. Annual penetration test (internal and external scopes). Business continuity tabletop. Disaster recovery test. Management review meeting with Q1 inputs. Mid-year risk register update. Vulnerability-scan trend review.
Q3 — Mid-year evidence audit and remediation. Self-assessment of control operation since the last certification. Identify evidence gaps from the first half of the year — controls that ran but didn’t produce proper evidence, or controls whose evidence storage has drifted. Remediate before the annual audit. Vendor reassessment for mid-tier vendors.
Q4 — Audit fieldwork preparation and event. Typically the heaviest operational quarter for SaaS companies running calendar-year observation periods. Evidence consolidation, auditor evidence requests, fieldwork support, report review. Also annual management review, vendor tier rebalancing based on the year’s risk signals, and next-year programme planning.
The four quarters aren’t rigid. Organisations running non-calendar observation periods rotate the shape. What matters is the pattern: one quarter per year is internal audit and governance, one is technical validation, one is mid-year correction, one is audit fieldwork.
Monthly recurring tasks
Monthly cadence activities don’t belong in the quarterly calendar because they happen every month. Miss them once and the audit catches it; miss them repeatedly and the audit catches the pattern.
Access reviews (sampled). Most organisations do full quarterly access reviews and lighter monthly spot-checks on high-privilege roles. The spot-checks catch drift between quarterly cycles.
Patching cadence. Vulnerability patching against SLAs declared in policy. Critical CVEs within the declared critical SLA; high within high SLA; and so on. Evidence: the patch management system reports showing SLA adherence.
Policy acknowledgements. New hires complete acceptable use and security policy acknowledgements within the onboarding window. Evidence: onboarding records.
Security metrics. Monthly metrics pack covering open findings, control failures, incidents, patching SLAs, training completion. Used as input to quarterly and annual governance reviews.
Incident review. Any security incident in the month, the investigation, and the remediation or acceptance. Evidence: incident tickets with resolution documentation.
Vendor inventory check. Monthly sanity check that the vendor inventory hasn’t drifted — new procurement the GRC team didn’t know about, vendors quietly expanded scope, sub-processors added without disclosure.
Annual activities
Five artefacts that only happen once a year but anchor the programme.
Internal audit (ISO 27001). Required annually; external internal-auditor engagement is typical for first-time programmes, sometimes replaced by internal staff once the team has depth.
Management review (ISO 27001). Clause 9.3 requires documented management review with specified inputs and outputs. An actual meeting with senior leadership, a written record, and action items.
Risk assessment refresh. Full re-run of the risk assessment methodology, updated asset inventory, updated threat landscape, updated residual risk evaluation. Output: revised risk register and updated SoA (ISO 27001).
Security awareness training. Documented refresh for all staff, including new content covering the year’s emerging threats. Attendance records retained.
Audit or surveillance event. SOC 2 fieldwork annually. ISO 27001 surveillance audit in years 1 and 2; recertification audit in year 3.
Cyber AI Profile considerations
For organisations with AI systems in scope — which is an expanding fraction of SaaS in 2026 — the NIST Cyber AI Profile (NISTIR 8596, preliminary draft released December 2025) adds a set of considerations that overlay the standard compliance calendar. The preliminary draft’s public comment period closed January 30, 2026; the initial public draft is expected later in 2026.
The practical implication for continuous compliance programmes: AI-related outcomes (securing AI systems, AI-enabled cyber defence, thwarting AI-enabled attacks) become subjects for periodic review in the same way other Cybersecurity Framework outcomes are. Organisations pursuing ISO 42001 already have this rhythm built into their AIMS. Organisations running SOC 2 and ISO 27001 without ISO 42001 can extend the existing management system to cover AI-specific outcomes rather than standing up a new management system.
What not to do: build a separate AI compliance rhythm disconnected from the main compliance cycle. Keep one calendar.
When automation is worth it, when it isn’t
The GRC automation market exists because continuous compliance at scale is genuinely hard to do with spreadsheets. The automation market also oversells. Both are true.
Automation is usually worth the cost when three conditions hold. First, scale — organisations with more than about 150 employees and a genuinely mature ISMS produce enough evidence volume that manual collection becomes a material engineering tax. Second, cross-framework operation — organisations running two or more frameworks benefit disproportionately because evidence collected once can satisfy multiple audit requirements, but only if the collection is structured. Third, dedicated compliance resource — someone whose job is to operate the automation, not an engineer doing compliance in their spare time.
Automation is usually not worth the cost when the organisation is small (under 50 employees), running one framework, and has competent technical leadership comfortable with structured spreadsheets. A well-organised shared drive with clear folder conventions, a compliance calendar in a project management tool, and disciplined cadence reviews beats a badly-operated expensive platform every time.
The honest middle ground: most mid-sized SaaS companies benefit from modest automation — integrations with cloud providers for control evidence, integrations with HR systems for onboarding evidence, integrations with ticketing systems for incident evidence — without paying for full-platform GRC suites. The automation ROI curve is real, but it’s not a linear “more automation equals better compliance” curve. It’s an S-curve where spending flattens past a point specific to your organisation.
One editorial position worth stating: organisations pursuing a GRC platform in 2026 should test the platform’s AI-compliance coverage specifically, not assume it parallels the platform’s 27001/SOC 2 coverage. ISO 42001, EU AI Act, and NIST Cyber AI Profile support varies significantly between platforms and the vendors that mention these standards most prominently are not always the ones that implement them best.
FAQ
What’s the difference between continuous compliance and continuous monitoring?
Continuous monitoring is a technical practice — automated, continuous observation of control operation. Continuous compliance is the broader operational discipline of keeping the whole compliance programme running on cadence, of which continuous monitoring is one component.
How often should we refresh our risk assessment?
Annually at minimum. More frequently if the business changes materially — new products, significant headcount change, major architectural shifts, new regulatory obligations, material security incidents.
Do we need an internal audit every year?
ISO 27001 requires internal audit of the ISMS on a planned schedule; annual is the typical cadence. SOC 2 doesn’t formally require internal audit but most mature programmes run one annually as self-assessment preparation.
Can we skip quarterly access reviews if we have just-in-time access?
Depends. JIT access reduces the steady-state privileged access surface but doesn’t eliminate it. The quarterly review cadence may compress (fewer standing entitlements to review) but the review process itself — including of the JIT grant history — usually still applies.
How much should we budget for a continuous compliance programme?
For a mid-sized SaaS, annual recurring compliance cost (tools, external audits, consulting, internal effort) typically runs 5–15% of engineering budget. Lower for single-framework programmes; higher for dual or triple framework organisations with international exposure.
Do we need a full-time compliance person?
Depends on scale. Organisations under ~100 employees often run compliance as part of a security engineer or security leader’s responsibilities. Between 100 and 500, a dedicated compliance lead or operations manager is usually justified. Above 500, a compliance team starts to make sense.
What evidence do auditors actually care about?
Evidence that controls operated on the declared cadence, produced the expected outputs, and that exceptions were handled per the declared process. Logs, tickets, meeting records, screenshots of control dashboards. Less “here’s a policy document,” more “here’s evidence the policy was followed.”
How do we handle controls that keep failing?
Document the failure, investigate root cause, remediate, and track. Repeated failures of the same control flag a design problem — the control may be poorly specified, under-resourced, or fundamentally unsuitable for the operational environment. Auditors read patterns of failure more critically than individual failures.
What happens to our programme during organisational changes (M&A, major growth)?
Material changes trigger scope review. An acquisition typically adds systems, people, and controls to audit; rapid growth changes the threat environment. Both should feed back into the risk assessment and potentially the SoA within the quarter after the change. Don’t defer compliance scope updates to the annual cycle when business changes are material.
Should we move to zero-trust architecture for continuous compliance?
Zero-trust and compliance frameworks are complementary. Zero-trust reduces standing privilege and improves logging, both of which simplify compliance evidence. But zero-trust architecture isn’t itself a compliance framework — the architectural posture needs to be mapped back to specific controls in whichever frameworks you run.