Continuous IT Compliance Monitoring: Detecting ISO 27001, SOC 2 and PCI DSS Security Gaps in Real Time
How to tie every control to a business objective, map it across frameworks, and prove it works between audits · October 2026
Most control failures are not design problems. A control looks fine on paper, the policy is signed, and the Statement of Applicability is in order. Then an access review is skipped for two quarters, a supplier’s certificate expires unnoticed, or a backup is never test-restored. Nobody finds out until the audit, or the incident.
The numbers back this up. KPMG’s analysis of controls assurance reports found that roughly one in five received a qualified opinion, and 83% of the exceptions behind those qualifications came from operating effectiveness, not design. The control existed. It just did not run as written.
The cost of that gap keeps rising. IBM’s 2026 Cost of a Data Breach Report puts the global average breach at USD 4.99 million, up 12% on the previous year, with an average of 247 days to identify and contain a breach. Verizon’s 2026 DBIR found that vulnerability exploitation (31%) has overtaken stolen credentials as the top way in, and that 48% of breaches involved a third party. Vulnerability management and supplier oversight are exactly the controls that tend to drift between audits.
This article sets out a practical approach to continuous control monitoring: link controls to the objectives they protect, map each control once across the frameworks you hold, test it on a schedule, and read the results where decisions get made.
How many frameworks does a typical organisation run?
Fewer than vendors suggest, but more than one team can manage on spreadsheets. Secureframe’s 2026 Cybersecurity and Compliance Benchmark Report found:
| Sl.No | Finding | Figure | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Average frameworks, companies with revenue above USD 100 million | 3.2 | |||||||||||||||||
| 2 | Average frameworks, companies with revenue below USD 5 million | 1.6 | |||||||||||||||||
| 3 | Organisations with one framework achieved or in progress | 46% | |||||||||||||||||
| 4 | Organisations with two frameworks | 31% | |||||||||||||||||
| 5 | Organisations with three frameworks | 17% | |||||||||||||||||
| 6 | Organisations with four or more | 4% | |||||||||||||||||
So a mid-size or enterprise organisation should plan for three to four frameworks running at once. For an Indian technology or services company selling to global clients, that usually means ISO/IEC 27001:2022, SOC 2, the Digital Personal Data Protection (DPDP) Act, and PCI DSS v4.0.1 wherever card data is in scope, with NIST CSF 2.0 often used as the internal reference model. Regulated BFSI entities add sector rules on top.
The work multiplies quickly. Hyperproof’s 2026 benchmark found that 76% of risk and compliance teams spend at least 30% of their time on repetitive manual tasks, and only 56% use a common control framework to rationalise overlapping requirements. Vanta’s State of Trust report puts compliance effort at 12 working weeks a year per team. The rest are collecting the same evidence three or four times for three or four auditors.
Where controls actually fail, framework by framework
Generic advice about “monitoring your controls” does not help an auditee. The failures below come up repeatedly in certification audits and attestation reports. Each one is a control that was designed correctly and then stopped operating.
| Sl.No | Framework | Control reference | Typical failure | What monitoring would catch | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | ISO/IEC 27001:2022 | A.5.18 Access rights | Periodic access reviews not done, or done without evidence of removals | Overdue review task; leavers still active after HR exit date | |||||||||||||||
| 2 | ISO/IEC 27001:2022 | A.8.8 Technical vulnerabilities | Critical patches outside the defined SLA; no risk acceptance recorded | Open criticals past SLA, by asset owner | |||||||||||||||
| 3 | ISO/IEC 27001:2022 | A.5.19 to A.5.22 Supplier relationships | Supplier assessments not refreshed; expired SOC 2 or ISO certificates on file | Supplier evidence past expiry date | |||||||||||||||
| 4 | ISO/IEC 27001:2022 | A.8.13 Backup; Clause 9.2 Internal audit; Clause 10.2 Corrective action | Backups never test-restored; internal audit programme slips; corrective actions left open | Last restore test date; open nonconformities past due | |||||||||||||||
| 5 | SOC 2 (2017 TSC) | CC6.2 / CC6.3 Logical access | Joiner and leaver tickets without approval; access not removed within policy window | Deprovisioning time against policy, per sample | |||||||||||||||
| 6 | SOC 2 (2017 TSC) | CC8.1 Change management | Production changes without approval or testing evidence | Changes deployed without a linked approved ticket | |||||||||||||||
| 7 | SOC 2 (2017 TSC) | CC7.1 / CC9.2 Monitoring and vendor risk | Vulnerability scans skipped in the period; vendor reviews missed | Scan coverage gaps by month; vendor review status | |||||||||||||||
| 8 | PCI DSS v4.0.1 | 8.2.6 Inactive accounts | User accounts inactive beyond 90 days not removed or disabled | Accounts with no login in 90+ days | |||||||||||||||
| 9 | PCI DSS v4.0.1 | 10.4.1.1 Automated log review; 11.3.1 Quarterly internal scans | Manual log review that does not happen; missed quarterly scan | Log review job failures; quarters without a clean scan | |||||||||||||||
| 10 | PCI DSS v4.0.1 | 12.5.2 Scope confirmation | Cardholder data environment scope not reconfirmed in 12 months | Scope review date against annual requirement | |||||||||||||||
| 11 | NIST CSF 2.0 | GV.SC Supply chain; DE.CM Continuous monitoring | Govern function adopted on paper with no owners or outcomes; monitoring gaps on new assets | Subcategories with no owner, no control, or no evidence | |||||||||||||||
| 12 | DPDP Act 2023 and DPDP Rules 2025 | Section 8(5) Reasonable security safeguards; Section 8(6) Breach intimation | Logs not retained as the Rules require; no tested breach notification process | Log retention status; last breach-drill date | |||||||||||||||
Two dates matter here. The transition from ISO/IEC 27001:2013 to the 2022 edition closed on 31 October 2025, so every certificate is now audited against the new Annex A, including newer controls such as A.8.9 configuration management and A.8.16 monitoring activities. PCI DSS v4.0.1 requirements that were future-dated became mandatory on 31 March 2025. In India, the DPDP Rules were notified in November 2025 with most obligations phased in over 18 months, and a failure to take reasonable security safeguards carries a penalty of up to ₹250 crore.
Map once, test once, report many
Most of the failures in the table above are the same control seen through different frameworks. Take a quarterly privileged access review. One well-run review, with one evidence pack, satisfies all of these:
| Sl.No | Framework | Requirement it satisfies | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | ISO/IEC 27001:2022 | A.5.18 Access rights; A.8.2 Privileged access rights | |||||||||||||||||
| 2 | SOC 2 | CC6.2 and CC6.3 | |||||||||||||||||
| 3 | PCI DSS v4.0.1 | 7.2.4 Review of user accounts and access privileges | |||||||||||||||||
| 4 | NIST CSF 2.0 | PR.AA-05 Access permissions managed with least privilege | |||||||||||||||||
| 5 | DPDP Act 2023 | Section 8(5) Reasonable security safeguards | |||||||||||||||||
This is the case for a common control framework: a single register where each control is written once, mapped to every citation it covers, owned by one person and tested on one schedule. Evidence is collected once and reused across the ISO surveillance audit, the SOC 2 Type 2 period and the PCI DSS assessment. When a control fails, you see every framework it puts at risk at the same time.
The logic: intent down, evidence up
A mapped control still needs a reason to exist. The strongest control programmes connect each control to the business objective it protects.
Direction flows down. The vision and mission set the goals, the goals break into measurable objectives, and each objective faces risks and carries obligations from ISO, SOC 2, PCI DSS, DPDP or contract. Controls are chosen to treat those risks and meet those obligations.
Evidence flows up. Tests, key control indicators and attestations show whether each control operates. Control results reduce or leave residual risk, and that residual risk is read against the objective it threatens.
Figure 1. Intent flows down from strategy to controls; evidence rolls back up to the objective.
Four questions every control must answer
A control is properly designed only when it can answer these four questions. Auditors ask versions of all of them.
- What does it protect? Name the objective, and the risk to it or the obligation behind it, such as ISO A.8.8 or PCI DSS 11.3.1.
- What does it implement? The control objective and policy it belongs to. A control with no control objective is an orphan, and orphans are where audit findings start.
- Who owns it, and how is it evidenced? A named owner, plus an indicator, test plan or attestation that proves it operates across the whole audit period, not just on audit day.
- How much does it matter? Whether it is a key control or mandated by regulation, which sets how often it is tested and how closely it is watched.
A control that protects no objective is a candidate for retirement. An objective whose risks have no controls is a visible gap, not a silent one.
How a control is tested and fixed
Controls are created from a control objective, assigned to the entities they cover (a business unit, an application, a supplier), and then tested on a schedule. A pass keeps the control compliant until the next test. A failure raises an issue, the issue drives a remediation task with an owner and a due date, and a retest closes the loop.
This is the same cycle ISO/IEC 27001 Clause 10.2 asks for with nonconformity and corrective action, and the same trail a SOC 2 auditor samples when an exception is reported. Running it continuously means the exception is found and fixed by you, inside the period, with evidence, rather than written up in the report.
Figure 2. The control lifecycle. Every failure becomes an issue that is tracked to a retest.
Building blocks of a control monitoring programme
Whatever platform you use, the same layers need to exist and be connected. The strategy layer is usually defined during implementation to fit the organisation’s operating model.
| Sl.No | Layer | Purpose | What it holds | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Vision, mission, goals | Direction and intent | Strategy hierarchy | ||||||||||||||||
| 2 | Objectives | Measurable outcomes with owners and KPIs | Objectives linked to risks and controls | ||||||||||||||||
| 3 | Risks | What could stop the objective | Risk statements with inherent and residual scores | ||||||||||||||||
| 4 | Obligations | What must be done | ISO 27001, SOC 2, PCI DSS, NIST CSF, DPDP citations; policies; control objectives | ||||||||||||||||
| 5 | Controls | The safeguard on each entity | Controls flagged key, mandated or exempted, mapped to every citation | ||||||||||||||||
| 6 | Evidence | Proof the control operates | Test plans, control tests, key control indicators, attestations | ||||||||||||||||
| 7 | Gaps | Failures and corrective work | Issues, nonconformities, remediation tasks | ||||||||||||||||
Measures that show whether controls are working
Report control performance through a small set of lenses. Each objective also needs its own outcome KPI, defined to fit what it is meant to achieve.
| Sl.No | Lens | Measure | What it tells you | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Coverage | Orphan controls; controls without indicators, test plans or attestations; framework citations with no mapped control | Whether every requirement has a control and every control is measured | ||||||||||||||||
| 2 | Priority | Key controls; mandated controls; key controls with failed indicators | Whether the controls that matter most are healthy | ||||||||||||||||
| 3 | Operation | Failed indicators; overdue test and indicator tasks | Whether monitoring actually runs and passes | ||||||||||||||||
| 4 | Effectiveness | Ineffective controls; failed control tests; average effectiveness | Whether controls achieve their intent | ||||||||||||||||
| 5 | Exposure | High residual risks; high risks with failed controls | What risk remains against each objective | ||||||||||||||||
| 6 | Responsiveness | Open issues and nonconformities; remediation tasks past due; average days to close | How quickly gaps are fixed, before the auditor samples them | ||||||||||||||||
| 7 | Audit readiness | Controls with complete evidence for the current audit period, by framework | How much of the next ISO, SOC 2 or PCI DSS audit is already evidenced | ||||||||||||||||
| 8 | Outcome | The objective's own KPI | Whether the objective is moving | ||||||||||||||||
A note on effort. Controls protect objectives, but they also cost time. Counting control tests and indicator tasks per quarter gives you a workload signal. A control that is expensive to run but guards little exposure is a drag on the team. The signal comes from reading effectiveness beside residual risk, as in Figure 3.
Figure 3. Reading control effectiveness beside residual risk tells you what to do with each control.
The review loop
At each objective review, the owner places every key control in Figure 3. Controls in the left column go back to remediation or redesign. Controls that are effective but still leave high exposure point to a gap in the control set, not in the control itself. Over time the organisation keeps the controls that protect its objectives and retires the ones that do not, which also shrinks the evidence burden for the next audit cycle.
Where to start: a 90-day plan
- Days 1 to 30. Build one control register. Pull controls from your ISO 27001 Statement of Applicability, SOC 2 control matrix and PCI DSS responsibility matrix, then deduplicate and map each one to every citation it covers.
- Days 31 to 60. Name an owner for every control, flag key and mandated controls, and set a test frequency and evidence standard for each. Start with access, vulnerability, change, backup and supplier controls, since that is where most findings come from.
- Days 61 to 90. Link key controls to the objectives and risks they protect, start reporting the measures above monthly, and run every failure through the issue-remediation-retest cycle.
Frequently asked questions
What is continuous control monitoring?
It is the practice of testing controls on a regular schedule through indicators, automated checks and attestations, instead of only during the annual audit. The aim is to find a control failure inside the audit period and fix it before it becomes a finding or an incident.
How many compliance frameworks does a typical company manage?
Secureframe’s 2026 benchmark found an average of 3.2 frameworks for companies with more than USD 100 million in revenue and 1.6 for companies under USD 5 million. About half of organisations run two or more.
What causes most SOC 2 exceptions and ISO 27001 nonconformities?
Controls that are designed correctly but not operated consistently: missed access reviews, late patching, unapproved changes, stale supplier assessments and untested backups. KPMG found 83% of exceptions behind qualified assurance reports came from operating effectiveness rather than design.
Can one control satisfy ISO 27001, SOC 2 and PCI DSS at once?
Yes, in most cases. A quarterly access review, for example, covers ISO 27001 A.5.18, SOC 2 CC6.2 and CC6.3, PCI DSS 7.2.4 and NIST CSF PR.AA-05. A common control framework records that mapping so the control is tested and evidenced once.
Does the DPDP Act require specific security controls?
The Act requires reasonable security safeguards, and the DPDP Rules 2025 set minimum measures such as access control, logging and log retention, and breach notification. Organisations already certified to ISO 27001 can map most of these to existing Annex A controls, then close the gaps.
Running ISO 27001, SOC 2, PCI DSS and DPDP in parallel?
We can map your existing controls into a single register and show you which ones would fail an audit today.
Book a control-mapping workshop
Xponential Digital