The certificate was the easy part.
Controls decay quietly. Staff change, systems get replaced, and the evidence stops being collected months before anyone notices. The next audit then costs what the first one did. This is the work that prevents that.
Certification is not the finish line.
Controls drift
A firewall rule that was correct on audit day gets a change ticket six months later and nobody updates the control description. Access lists grow because it’s easier to add than to revoke. None of this shows up as one dramatic failure — it shows up as a gap between what the policy says and what the systems actually do.
Evidence gaps are retrospective
You cannot produce October’s access reviews in March if nobody ran them in October. Auditors ask for evidence covering a period that has already passed, and by the time the request lands it’s too late to go back and create what should have existed all along.
Frameworks re-assess on a cycle
A SOC 2 Type II report covers a defined observation window and needs a new one to stay current. ISO 27001 certification runs a three-year cycle with annual surveillance audits in between. Whatever applies to you, the clock toward the next assessment starts the day the last one ends.
Evidence collection.
An auditor doesn’t take a control’s existence on trust — they ask for proof it operated as described, and proof produced continuously reads very differently to proof assembled the week the request lands.
Cadence follows the control, not the calendar: some evidence is a system-generated log captured continuously, and some needs a person to run a review and sign off on a schedule tied to how much that control matters. What counts is that it’s captured close to when the control operated, not reconstructed once someone asks for it.
We keep it organised in a structure mapped to the framework’s control set, so when the request lands it’s a matter of handing over what’s already there, not working out what exists and where.
- Access reviews and de-provisioning records
- Change management tickets and approvals
- Vulnerability scan results and remediation evidence
- Security awareness training completion
- Incident and exception logs
- Vendor due-diligence records
Control monitoring.
Not every control needs the same level of attention. Some run themselves and only need periodic confirmation; access to production systems, encryption configuration, and vendor security postures are the ones that actually change, and they need someone checking on a schedule instead of only at audit time.
Each recurring control has an owner who signs off that it ran and produced what it should have. That accountability is what an auditor is really testing when they sample evidence — not just that a control exists, but that someone is responsible for it operating.
When a check turns up a failure — a terminated employee still holding access, a scan that didn’t run, a policy nobody reviewed on schedule — it gets logged as an exception, remediated, and the remediation itself becomes evidence. No framework expects zero exceptions; it expects a process that catches and closes them.
Much of it is a byproduct of monitoring you may already have. Continuous security monitoring generates the logs and alert history that double as operating evidence for the controls a framework asks about, instead of a separate exercise run just to satisfy an auditor.
Vendor and third-party risk.
Most frameworks hold you responsible for the vendors that touch your data, not just your own systems. A payment processor, a cloud host, or a subcontractor with production access all inherit your obligations the moment they’re in the chain.
New vendors go through an intake review before data or access changes hands: what they can reach, what they do with it, and what their own security posture looks like. Existing vendors get reviewed again on a schedule, because a vendor that passed review two years ago may have changed ownership, subprocessors, or security practices since.
That register is what most frameworks require in some form, and what most companies discover they need only once an auditor asks for it — by then it’s a research project instead of a lookup.
- Vendor name and what they can access
- Data handled and its classification
- Security certifications or attestations on file
- Last review date and the next one due
- Contract and data processing terms
Policy lifecycle and audit liaison.
Policies age the same way controls do. A document written for last year’s infrastructure or last year’s org chart stops describing what actually happens, and an auditor testing against a stale policy finds a mismatch before they find anything else.
Each policy has an owner and a review cadence, and every review — whether it changed the document or confirmed it still holds — gets an approval record. That record is itself evidence: it shows governance is active, not just that a policy exists somewhere.
When an assessment approaches, we assemble the evidence package in the format the auditor expects and answer the bulk of their information requests directly, so the questions that do reach your team are the ones only your team can answer.
The re-assessment cycle.
Continuous collection
Evidence keeps accumulating between assessments instead of starting from zero when the next one is announced.
Pre-assessment review
We check the evidence against the framework before the auditor does, while there’s still time to close what’s missing.
Package assembly
Everything the auditor will ask for, organised against their control mapping and ready to hand over on day one.
Assessment support
We sit with you through fieldwork and answer the auditor’s follow-up requests directly.
Findings closed, baseline reset
Findings get remediated and folded into the monitoring baseline, so the next cycle starts from where this one ended, not from scratch.
Stop rebuilding the evidence package every year.
A continuous-compliance engagement keeps evidence current between assessments, so the next one starts from a maintained baseline instead of a scramble.