The gap between audits
ISO 27001 and SOC 2 audits happen once a year, sometimes less frequently. In between, systems still change, teams still scale, and vendors still get added.
For IT teams managing compliance through spreadsheets and Drive folders, those changes accumulate without visibility. By the time the next audit arrives, some of them have become problems.
Here are the five gaps that show up most consistently in this pattern.
1. Accounts that aren't revoked after employees leave
This is the most common gap, and the easiest to underestimate.
When an employee leaves, HR runs offboarding and IT disables the email account. But what about everything else: AWS IAM users, GitHub repo access, database credentials hardcoded in an old project, accounts in SaaS tools used only by that team?
Without centralized access tracking, those accounts often aren't reviewed systematically. They persist, not active, but not deleted either.
This is an operational problem, not just a compliance finding. Orphaned accounts are attack vectors. If those credentials were leaked through a breach at another service (credential stuffing is common), an attacker can use them without anyone noticing quickly, because the account looks inactive.
ISO 27001 Control 9.2.6 and SOC 2 CC6.2 require periodic review. But the real value isn't satisfying the auditor. It's knowing your systems don't have hidden back doors.
2. Evidence gaps that accumulate silently
SOC 2 Type 2 audits require continuous evidence throughout the observation period, typically six to twelve months. The auditor isn't just asking "are you doing X?" but "have you done X consistently for the past nine months, and do you have evidence?"
For IT teams managing compliance reactively:
- Screenshots get taken quickly when the auditor asks
- Logs get exported from the system for whatever time range is still accessible
- Access reviews happen right before the audit, not on an actual schedule
Evidence exists for some controls, is missing for others, and much of it lacks clear metadata about when it was collected and for which control.
IT teams typically spend two to four weeks preparing for each audit, most of it finding and compiling evidence that should have been organized from the start.
3. Vendor risk that isn't monitored after onboarding
Many teams have solid vendor assessment processes at onboarding: security questionnaire, certification check, DPA or BAA signed. After that, the vendor gets marked "approved" and nobody looks at them again.
But vendors change over time:
- New subprocessors added without prominent notice
- Certifications expire and aren't renewed
- The vendor gets acquired and service terms change
- A security incident on the vendor's infrastructure affects your data
Without periodic vendor review built into the compliance workflow, these changes typically go undetected until something goes wrong, or until an auditor asks about your vendor management program.
For companies handling PHI or PII, this isn't abstract risk. Many real breaches start at third-party vendors, not in internal systems.
4. Configuration drift that goes undetected
Infrastructure changes constantly in cloud environments. An engineer opens a port in a security group for testing, then forgets to close it. A team creates an S3 bucket with public access to share files temporarily, and nobody thinks about that bucket again. A database has logging enabled, but after an infrastructure update, the setting resets to default.
These changes make sense at the time they happen. The problem is the absence of any mechanism to track whether the current configuration still matches the approved baseline.
This is configuration drift, and it happens not because anyone intentionally did something wrong, but because there's no continuous visibility.
Compliance frameworks require periodic configuration reviews not to add work, but because this is the only type of drift you can find by looking.
5. Training gaps hidden in a fast-scaling team
When a company scales from 20 to 60 people in a year, onboarding gets stretched and security training gets cut short. New hires get onboarded, learn the tools, join the sprint, but HIPAA training, data handling policy, and incident reporting procedures aren't completed.
This isn't visible immediately. The team operates normally. Nobody sees the problem because nothing is being tracked.
Six to nine months later, a meaningful portion of the team is handling customer data without fully understanding what they are and aren't allowed to do. Human error in PHI or PII handling usually doesn't come from malicious intent. It comes from not knowing.
Why these problems coexist
All five gaps share one characteristic: they have no visible symptoms until they become incidents.
Orphaned accounts don't cause errors. Evidence gaps don't slow the system. Vendor risk doesn't show on a dashboard. Configuration drift doesn't trigger alerts. Training gaps don't produce any logs.
They only surface when an auditor asks, when an incident occurs, or when an enterprise customer runs vendor due diligence and asks you to demonstrate compliance.
Continuous compliance tracking doesn't create extra work. It makes work that already needs to happen visible and manageable before it becomes a crisis.
A place to start
You don't need to change every process at once. Start with a simple question: in the past 30 days, which controls did your team run, and is there evidence for them?
If the answer takes more than five minutes to find, that's a signal worth paying attention to.
See how pTrackly organizes continuous evidence collection to start with the most specific gap in your current workflow.