We opened our recent webinar with a live poll: What usually triggers your team to recheck whether your compliance setup is still current?
The winner, by a wide margin, was an upcoming audit.
That answer, while honest, is also the problem.
Between audits, people leave, tools get added, vendors come in, and control owners change jobs. None of that is unusual. The trouble starts when the compliance program does not keep up, because the next request for proof rarely waits for audit season. It comes from a buyer’s security team mid-deal, an insurer before underwriting, or a board that wants more than a status update.
So instead of discussing readiness in the abstract, we put a compliance program on screen and asked three reviewers to tear it apart.
The case file: ready on paper, drifting underneath
The case was built from customer interviews and survey data. It followed a late-Series-A B2B SaaS company preparing for a Series B. The company had completed a clean SOC 2 Type II audit nine months earlier, was preparing for renewal, and had ISO 27001 on the horizon.
On paper, it looked mature enough to inspire confidence.
The panel then reviewed the setup through four connected views: what exists, who has access, what can be proven, and what has changed.
Ben Rothke (Senior Information Security Manager at Experian) brought the security and risk lens. Dallas Baker (Senior GRC Analyst at Sensiba LLP) brought the auditor’s perspective. Nik Pegler (Information Security and Compliance Analyst at Balboa Travel) brought the practitioner’s view.
The gaps did not appear as one dramatic failure. Instead, they accumulated across inventory, access, evidence, and drift.
Here are five takeaways compliance and security teams should take away from the session.
1. Your last audit report is already a historical document
Dallas made the point plainly: a clean SOC 2 report is always a positive, but SOC 2 looks backward at a historical period. Nine months later, with new AI tools, new contractors, expanded infrastructure, and new vendors in the environment, buyers are less interested in the report itself and more interested in whether your governance traveled with the changes.
Ben framed the same idea through scope. If you want to go to Rome, Italy, and you book a flight to Rome, New York, everything after that goes wrong efficiently. Scope is the destination, and if it has quietly changed since the last audit, the whole trajectory is off.
His analogy for the fix stuck with everyone:

What leading teams are doing differently: They treat the audit report as a snapshot, not a shield, and keep governance moving at the same speed as the business.
2. Screenshots in a folder are not evidence
The access review screen produced the most visceral reactions. Two systems had never been reviewed. One review consisted of screenshots saved in a folder.
Nik went straight to the last review column. “Never reviewed” is a glaring indicator, but his sharper point was about the screenshots: they are meant to look like an audit trail, and they fail to prove that access is actually controlled.
Dallas explained exactly what would hold up instead. At a minimum, evidence of an access review needs to show who performed it, what system it covered, when it was completed, what was reviewed, and what remediation followed. A full export with visible parameters beats a screenshot every time, because the remediation trail is half of the control most teams forget to capture.

Ben added the account types that deserve the most suspicion: service accounts and admin accounts with passwords that never rotate. His word of caution was the word itself. “Assume” is a scary word in compliance.
What leading teams are doing differently: They design evidence to answer an outsider's questions, not to reassure the internal team.
3. AI tools are entering the stack faster than governance can catch them
The case file included two AI tools added after the last audit, with no vendor or security review. One touched support tickets. The other recorded sales and customer calls, and sat outside SSO on a standalone login.
When asked to rank everything that had changed in the environment, Dallas put this at the top, specifically because of the customer data flowing through unreviewed systems outside the corporate login.
Nik was equally direct about how buyers see it. A buyer’s security team will absolutely catch this in due diligence, not because they are hunting for shadow IT, but because they are looking for inconsistencies in the architecture. Sensitive data in systems outside the centralized identity provider is exactly that.

The panel’s fix was unglamorous and effective: a formal vendor intake process, where review, risk assessment, and ownership assignment happen before a tool reaches production rather than being discovered during the next audit.
What leading teams are doing differently: They route every new tool, AI included, through intake before it touches customer data, not after an auditor finds it.
4. Manual compliance can work. Unstructured manual compliance does not scale.
This was the panel’s most interesting disagreement. Ben argued that for a company this size, manual evidence collection is manageable. With a small user base and good oversight, it is a reasonable approach. Boeing cannot get by on manual reviews. A 50-person SaaS company can.
Nik agreed it is doable, then named the catch: it is completely unscalable, and this company is actively courting investors. Relying on human follow-through introduces a persistent point of failure, and by the time an auditor or customer comes knocking, manually gathered evidence is almost always stale.

His practical middle ground, for teams not ready to automate collection itself: automate the reminders. Nik runs evidence collection through ITSM tickets generated automatically on daily, weekly, monthly, and quarterly cadences, so nothing depends on someone remembering.
He treats the whole program like military maintenance: done periodically, the work stays bite-sized. Fifty vendor reviews spread across a year is a few per month. Fifty vendor reviews in audit week is a crisis.
What leading teams are doing differently: They remove memory from the process, whether through full automation or automated accountability.
5. Readiness usually breaks through accumulation, not one dramatic event
The final screen showed every change since the last audit in order: support team growth, contractor expansion, new analytics, the two AI tools, and a risk register that had not moved since the audit closed.
Nik called it the classic case of drift. Individually, every change on the timeline is normal, even positive. Collectively, they rewrite the environment, and if none of it is mapped against the risk register, you end up testing against an environment that no longer exists.

Ben's priority, if the team could only recheck one thing: access reviews. Admin accounts are what attackers go after. He pointed to the MGM ransomware attack, where threat actors went through the help desk and accounts with root access rather than any exotic vulnerability.
Dallas closed with the habit that prevents the pile-up: tie governance reviews to significant changes, not just the calendar. A new system, vendor, process, or team should automatically trigger a conversation about risk, applicable controls, and the evidence the next audit will need. The halfway point between audits is a good checkpoint. Change-driven reviews are better.
What leading teams are doing differently: They let organizational change, not audit dates, set the review cadence.
The hot take round: Agree, disagree, or on the fence
We closed the case file with a rapid-fire round. Each panelist got a bold statement and three options: agree, disagree, or on the fence. The verdicts were sharper than the format suggests.
Statement 1: “A gap assessment right before the audit is already too late.”
Ben agreed wholeheartedly. His rule of thumb: the halfway point between audits is when gap-hunting should start, roughly six months out, before the audit pressure is on.
Dallas added that major business or technology changes should trigger an earlier reassessment.
Statement 2: “A good compliance program should fix every gap with the same urgency.”
Nik strongly disagreed. Gaps get prioritized like vulnerabilities: a documentation gap is annoying but manageable, a control gap jumps the queue. Treat every gap as a five-alarm fire and you burn out the team until nobody takes the critical ones seriously.
Ben backed him with the analogy of the night:

A physician reading your blood test knows which elevated number matters and which is noise. Compliance teams with limited staff and budget need the same big-picture read.
Statement 3: “Continuous compliance takes less effort and stress than getting audit-ready right before the deadline.”
Nik agreed 100 percent, pointing back to his maintenance-program approach: done periodically, the work becomes smaller, more predictable, and easier to absorb alongside normal operations.
Statement 4: “Controls should fit how teams actually work, but the evidence should make sense to someone outside the team.”
Dallas agreed that controls should be designed around real business processes rather than artificial audit theatre.
Evidence, however, still needs to answer basic questions clearly: who performed the control, when it happened, what was reviewed, and what action followed.
Nik added an important qualification. Some control objectives are non-negotiable.

His broader point: many frameworks are written for enterprises, and the realities of an SMB with one security person wearing three hats do not always bend to fit. Sometimes the org chart has to move, not the control.
Both points can be true: the implementation should fit the business, but the underlying control objective still has to hold.
The version that gets tested is the one you have today
Passing your last audit proved your program was okay at that specific moment. That moment is gone.
The version an auditor, a buyer, or your own board will test is the one running today, and the gaps between the two do not announce themselves. They compound quietly, in the small changes nobody is rechecking.
The teams that hold up under scrutiny are not the ones with more policies or thicker evidence folders. They are the ones who can answer a hard question on a Tuesday without calling a meeting first.
If you want to pressure test your own program before someone else does, the panel’s resource pack is a practical place to start: the Compliance Gap Assessment Workbook for evidence readiness, ownership gaps, and remediation priorities, and the 30-day Compliance Starter Plan for a week-by-week path to closing them.
Or watch the full webinar on demand and see how much of the case file looks uncomfortably familiar.

Susmita Joseph is a cybersecurity and compliance writer specializing in governance, risk, and regulatory content. She focuses on making complex subjects such as AI governance, cybersecurity compliance, and risk management accessible to growing and mature organizations. With a particular interest in the intersection of AI and GRC, her work explores how emerging technologies are reshaping compliance expectations and security operations.

Barasha Medhi is a product marketer at Scrut Automation who focuses on making compliance easy to understand and easier to apply in the real world. She creates customer-facing guidance that explains not just what a feature does, but how it fits into the day-to-day work of getting audit-ready and staying that way. Her work connects the dots across frameworks, controls, evidence, and ownership, helping teams use the full breadth of Scrut’s platform with clarity and confidence.










.png)













