Continuous compliance: why the audit is the easy part

This post is for founders and engineering leads who have just passed a first SOC 2 or ISO 27001 audit, or are about to. The first audit gets the attention. The second one is where teams get caught out. By the end you will know why compliance drifts after year one, which controls slip first, and how to set up a rhythm so the next audit is a review of records you already have, not a scramble.

On this page

• Why the first audit is the easy part

• What auditors look at after year one

• Where compliance drifts

• What continuous compliance actually means

• Building an operating rhythm

• Security and compliance in one loop

• How NexusVoid helps

Why the first audit is the easy part

A first audit is a project with a deadline. A customer asks for a report, a date gets set, and the team rallies. Policies get written, MFA gets enforced, laptops get encrypted, someone runs the first access review, and evidence is gathered into folders. It is hard work, but it has a clear finish line and everyone is paying attention.

Then the report arrives and the deadline is gone. The person who drove the project goes back to their day job. The controls are still on paper, but nothing is pushing them to happen. Nobody decided to stop doing access reviews. They just stopped being anyone’s top priority.

The trouble is that year two is graded on what happened while nobody was watching.

What auditors look at after year one

SOC 2 Type II

A SOC 2 Type I report looks at whether controls are designed properly at a single point in time. A Type II report tests whether they operated effectively over an observation period. Many companies start with a Type I or a short first Type II window, then move to a 12-month period renewed each year, because enterprise customers expect a current report.

Auditors test Type II by sampling. They pick employees who joined during the period and check each one was trained and signed the policies. They pick people who left and check access was removed on time. They pick code changes and check each was reviewed. One quarter where reviews lapsed shows up as an exception in the report, and your customers read exceptions.

When a customer needs assurance for the gap between your last report and today, you give them a bridge letter. Your own management writes it, not the auditor, so it only carries weight if your controls kept running.

ISO 27001

An ISO 27001 certificate runs on a three-year cycle. After the initial certification audit, the certification body returns for surveillance audits, usually once a year, and a full recertification audit comes before the certificate expires. In between, the standard expects you to run your management system: internal audits and management reviews at planned intervals, a risk assessment that stays current, and corrective action when something goes wrong. Surveillance auditors look for evidence that the system is alive, not just that the documents exist.

Where compliance drifts

Drift is rarely dramatic. It is small recurring tasks that quietly stop, and changes nobody connected to compliance. Here are the controls that slip most often, with typical cadences. Your own policies set the real cadence, and auditors test you against what you wrote.

Two other sources of drift are worth naming. The first is scope change: a new cloud account, a new region, a new product or an acquisition that nobody mapped into the control set. The second is policy that promises too much. If your policy says access reviews happen monthly and you only manage quarterly, every missed month is an exception. Write the cadence you can actually keep.

What continuous compliance actually means

Continuous compliance is not a product category or a new framework. It is a way of operating with three parts.

Evidence collected as work happens

The best evidence comes straight from the systems: MFA status from your identity provider, encryption settings from your cloud account, branch protection and pull request reviews from GitHub, disk encryption and screen lock from employee devices. When that is pulled automatically and kept with timestamps, you never need to reconstruct the past from screenshots.

Owners and due dates for the human tasks

Some controls cannot be automated: an access review needs a manager’s judgment, a risk assessment needs a conversation, a tabletop needs people in a room. Each of these needs one named owner, a due date and a reminder. Shared ownership means no ownership.

Drift detection that reaches the owner fast

When a check fails, such as a new S3 bucket that is public, an engineer without MFA or a laptop with encryption off, the owner should hear about it within days. A problem fixed in a week is barely visible in a Type II sample. The same problem found eleven months later is an exception.

Building an operating rhythm

Here is a simple rhythm that works for most startups between 10 and 200 people. Adjust it to match your policies.

• Weekly: review failing automated checks and new security findings, and assign each an owner.

• Monthly: check onboarding and offboarding against HR records, review open vulnerabilities against SLAs, and confirm new vendors were reviewed.

• Quarterly: run user access reviews for production and critical SaaS tools, and review the risk register for anything new.

• Yearly: refresh the risk assessment, review and re-approve policies, rerun security training, test a backup restore, run an incident tabletop, review critical vendors and commission a pentest.

• On change: when you add a cloud account, product or major vendor, map it into scope before it goes live.

One person should own the calendar, often an engineering lead or head of operations. Control owners sit across the company. The goal is that nothing important depends on anyone remembering.

Security and compliance in one loop

Compliance often lives apart from security work. Engineers fix vulnerabilities in one tool, while someone else collects screenshots for the auditor in another. That split is where most of the wasted effort sits.

The strongest evidence is a fix that actually happened. When a finding in your code or cloud becomes a pull request, the merged fix is retested, and the result is filed against the controls it satisfies, the audit trail writes itself. You end up with proof that you find problems, fix them and verify the fix, which is what auditors and customers want to see.

Think of it as one loop: detect a problem, prove which controls it touches, resolve it, test the fix, verify it held. Run that loop continuously and compliance stops being a separate project.

How NexusVoid helps

NexusVoid runs your security program for you, like an autonomous CISO, and compliance comes out of that work as a by-product. Our loop is Detect, Prove, Resolve, Test, Verify, and it runs every day, not every audit.

Aegis collects evidence automatically from your cloud, GitHub, identity provider and devices, maps it to shared controls across SOC 2, ISO 27001, DPDP and other frameworks, and flags drift as it happens. It also runs the human side: policies tailored to your company, the risk register, vendor management, employee security training and auditor-ready exports. Argus finds issues starting from the outside like an attacker, then working inward through code, dependencies, cloud and secrets. It opens fixes as pull requests, retests when they merge and files the evidence against the controls they satisfy. Striker runs pentests on demand for your yearly test or a major release.

Auditors stay independent. We get you ready, and keep you ready.

Frequently asked questions

How often do we need a new SOC 2 report?

SOC 2 has no formal expiry, but most customers treat a report older than about a year as stale. That is why most companies run back-to-back 12-month observation periods and issue a new Type II report each year. Use a bridge letter to cover the gap between the end of your last period and the day a customer asks.

Can we backfill missing evidence before the audit?

No. If an access review did not happen in the second quarter, creating a record for it later is misrepresentation, and auditors check timestamps. The honest path is to tell the auditor, show when the control resumed and what you changed to stop it lapsing again. An exception with a credible fix is far better than a fabricated record.

Does continuous compliance mean continuous auditing?

No. Your auditor or certification body still visits on their schedule and reaches their own conclusions. Continuous compliance is about your side: controls run all year and evidence is captured as it happens. The audit itself becomes faster, because the auditor is reviewing records rather than waiting for you to build them.

Who should own compliance after the first audit?

One person should own the program and the calendar, usually an engineering lead, head of operations or security lead. Individual controls belong to the teams that run them: IT for devices, engineering for change management, HR for onboarding and training. A founder should still review status every month.

Does automation replace a security or compliance hire?

It replaces most of the repetitive work: collecting evidence, chasing reminders, mapping controls and spotting drift. It does not replace judgment on risk, access decisions or incident response. Startups without a CISO can use it to act as one. Startups with a CISO or vCISO use it to free that person from collecting screenshots.

If your first audit is behind you and you want year two to be quieter, talk to a founder. Book a call at /contact and we will look at your controls and evidence with you.