In brief
Continuous compliance tracking surfaces five operational gaps that build up between audits; this guide shows IT leaders what drifts and how to catch it.
Continuous compliance tracking means running each recurring control (access reviews, evidence collection, vendor checks, configuration checks, training) on a schedule and recording the result, instead of reconstructing it before an audit. Without it, five operational gaps build up between ISO 27001 or SOC 2 audits: orphaned accounts, missing evidence, unmonitored vendors, configuration drift and untrained new hires.
Why do gaps build up between audits?
A certification audit looks at your controls once a year, and an ISO 27001 certificate is kept through yearly surveillance audits within a three-year cycle. Between those visits, systems change, the team grows and vendors are added. When compliance lives in spreadsheets and shared folders, nobody sees those changes until the next audit, and by then some have become real exposure. The five gaps below are the ones that show up most often, and each maps to a control that the frameworks already expect you to run continuously.
| Gap | What it looks like | Framework reference |
|---|---|---|
| Orphaned accounts | Leavers keep access to cloud, code or SaaS tools | ISO 27001:2022 A.5.18; SOC 2 CC6.2, CC6.3; PCI DSS 7.2.4 |
| Evidence gaps | Proof exists for some months and not others | SOC 2 Type II period of operation; ISO 27001 clause 9.1 |
| Vendor drift | Approved vendors are never re-checked | ISO 27001:2022 A.5.22; SOC 2 CC9.2; PCI DSS 12.8.4 |
| Configuration drift | Temporary changes become permanent | ISO 27001:2022 A.8.9; SOC 2 CC7.1 |
| Training gaps | New hires handle data before training | ISO 27001:2022 A.6.3; HIPAA 164.308(a)(5); PCI DSS 12.6 |
Why do accounts survive after employees leave?
Offboarding usually disables the email account and stops there. Cloud IAM users, repository access, database credentials and team-specific SaaS accounts sit outside that checklist, so they persist: not active, not deleted. That is an operational risk before it is an audit finding, because a dormant account with reused credentials can be used without anyone noticing. ISO/IEC 27001:2022 control A.5.18 covers provisioning, review and removal of access rights; SOC 2 criteria CC6.2 and CC6.3 cover removing access that is no longer authorized; PCI DSS v4.0.1 requirement 7.2.4 asks for a review of user accounts at least every six months. A scheduled access review that covers every system, not only email, is the fix.
How do evidence gaps accumulate without anyone noticing?
A SOC 2 Type II report covers how controls operated over a period, typically 3 to 12 months; the AICPA sets no minimum. The auditor asks whether a control ran consistently across that period and wants proof for each instance. Reactive teams take screenshots when asked, export whatever logs are still retained, and run the access review just before fieldwork. The result is evidence for some months, gaps for others, and files with no record of when they were collected or for which control. Tracking each evidence item as a recurring task with a frequency, an owner and a review date is what closes this gap; see automated evidence collection for how that works in practice.
Why does vendor risk go unmonitored after onboarding?
Most teams assess a vendor once: questionnaire, certificate check, DPA or BAA signed, marked approved. After that, vendors change. They add subprocessors, let a certification lapse, get acquired, or have an incident. ISO 27001:2022 A.5.22 asks you to monitor and review supplier services, SOC 2 CC9.2 covers vendor risk, and PCI DSS 12.8.4 requires monitoring service providers' PCI DSS compliance status at least once every 12 months. A periodic vendor review with expiry dates for certificates and agreements turns this from a one-off into a routine.
What is configuration drift and why is it invisible?
Configuration drift is the gap between the approved baseline and what is actually running. An engineer opens a security group port to debug and forgets it; a bucket is made public to share a file; a logging setting resets after an update. Each change made sense at the time. ISO 27001:2022 A.8.9 covers configuration management and SOC 2 CC7.1 covers detecting configuration changes that introduce vulnerabilities. The only way to catch drift is to check it on a schedule, ideally with automated cloud checks rather than manual review.
How do training gaps hide in a growing team?
When a team grows quickly, new hires learn the tools and join sprints, but security awareness, data handling and incident reporting training slip. Nothing breaks, so nobody notices, until months later part of the team is handling customer data without knowing the rules. ISO 27001:2022 A.6.3, the HIPAA Security Rule at 45 CFR 164.308(a)(5) and PCI DSS 12.6 all require security awareness training, and auditors check completion for everyone in scope, including recent joiners.
What do the five gaps have in common?
None of them produces a symptom until it becomes an incident or a finding. Orphaned accounts throw no errors, evidence gaps do not slow systems, vendor changes do not appear on a dashboard, drift does not alert, and missed training leaves no log. They surface when an auditor asks, when an enterprise customer runs due diligence, or after something goes wrong. Continuous compliance tracking makes work the frameworks already require visible on a schedule, which is why it works as an early warning system rather than overhead.
How do you turn each review into an early warning signal?
The difference between a checkbox for the auditor and a risk "sensor" is whether anyone looks at the trend. Every recurring review produces a number: accounts removed in the access review, vendor certificates or DPAs about to expire, failed cloud checks, overdue evidence tasks, people in scope without training. A number that rises from one run to the next shows that an upstream process (offboarding, provisioning, change management) is leaking risk, weeks before it becomes an incident. A workable routine:
- Pick one number per gap in the table above, for example "accounts removed in the access review".
- Record it every time the review runs, in the same place as the evidence.
- Compare it with the previous run; a rising number is the warning, a flat or falling one shows the upstream process works.
- When a number rises, fix the cause, not only the instance: change the offboarding checklist, the provisioning template or the change process.
- Review the numbers in the management review that ISO 27001 clause 9.3 already requires, so they reach someone who can change the process.
In SaaS and IT outsourcing companies without a full-time compliance officer, where the CTO or a senior engineer carries it, reading five numbers on a schedule is realistic; reconstructing a year of evidence before each audit is not. What matters is that reminders, overdue items and failed checks arrive without anyone having to remember them.
A simple test: list the controls your team ran in the last 30 days and find the evidence for each. If that takes more than a few minutes, the gaps above are probably already there. For the wider picture of what keeping a certification involves, read maintaining compliance after certification.
How does pTrackly help with continuous compliance tracking?
pTrackly turns each recurring control into an evidence task with a frequency, an owner and a review date. It warns the owner 7, 3 and 1 days before a review is due, sends owners a weekly digest of open tasks, and escalates tasks overdue by 7 days to the assignee's manager and by 21 days to owners. Access reviews pull accounts from people and roles, Google Workspace apps and per-person app records, can repeat monthly to yearly, and never let anyone review their own access. Cloud tests check AWS, Google Cloud, Azure and Cloudflare configurations, and can run daily as evidence. The vendor register warns before certifications, DPAs and BAAs expire, and the built-in training course records completions as evidence. Your team still owns the decisions: who keeps access, which vendor risk is acceptable, how a finding is fixed. See how pTrackly supports teams after certification.
Frequently asked questions
What is continuous compliance tracking?
It is running recurring controls such as access reviews, evidence collection, vendor reviews and configuration checks on a fixed schedule, with an owner and a record of each run. The aim is to know your compliance status today, not only on audit day.
How often should access reviews run?
PCI DSS v4.0.1 requirement 7.2.4 sets at least every six months for user accounts. ISO 27001 and SOC 2 leave the interval to your risk assessment; quarterly is common for production systems and privileged access.
Does continuous tracking replace the annual audit?
No. The certification body or CPA firm still performs the audit and issues the certificate or report. Continuous tracking means the evidence for the whole period already exists when the audit starts.
How is compliance tracking different from security monitoring tools?
Monitoring tools watch events in real time. Compliance reviews look at slower-moving risk, such as who still has access, which vendors changed and whether controls ran at all. The two complement each other.
Which gap should a small team fix first?
Start with access: run one complete access review across cloud, code and SaaS accounts and remove what is no longer needed. It removes real risk immediately and is the control auditors test most often.
