Compliance Packs & Audit Readiness

What is actually in a compliance pack?

Four layers, and most packs sold as complete only contain the first. Policies state what your organisation has decided and who is accountable. Procedures describe how each decision is carried out. Standard operating procedures take the tasks that must be performed identically every time and write them down step by step, so the outcome does not depend on which person did it.

Those are what an assessor asks to see when they want proof rather than intent.

Behind all four sits the thing a pack has to do that a document set on its own cannot, which is stay true. A compliance pack has three jobs: describe your controls accurately, prove those controls actually work, and stay current as your environment moves.

A folder of documents does the first job approximately, does nothing for the second, and starts failing the third the week after it is written. That is why we treat the pack as a live artefact tied to the framework you are being measured against, rather than a deliverable that gets signed off and filed.

Is this IT compliance or company-wide compliance?

IT compliance, and the distinction is worth settling before you buy anything, because most frameworks reach further than the IT estate and almost every supplier is vague about where they stop.

What we cover is the part an assessor asks IT to produce and evidence. That is the substantial half of Cyber Essentials, most of the Annex A controls in ISO 27001 that anyone actually gets audited on, and nearly all of a customer security questionnaire.

What is not ours is the rest of the organisation: HR policy and employment matters, finance controls and segregation of duties, health and safety, quality management, and the business continuity planning that covers premises and people rather than systems. Those belong to the people accountable for them, and a supplier who offers to write your HR policy alongside your firewall configuration standard is selling documents rather than compliance.

That is a boundary on who does the work, not on what the platform can produce. EtherAssist generates documents for those wider areas perfectly well, and businesses use it that way, so if you want one place for the whole set it is available to you. What changes outside IT is that somebody in the business has to own the content, because a policy nobody in that function agreed to is exactly the kind of document that fails an audit for being unevidenced.

Policies, procedures and SOPs: what is the difference and why does it matter?

A policy is a decision with an owner. It says what your organisation permits and requires, and it should be short, readable and approved at the right level, because it is a management commitment rather than a technical manual. An access control policy states that access is granted by role, reviewed periodically and removed on the day someone leaves. It does not say which button to press. Policies change rarely and are the documents an auditor traces accountability through.

A procedure explains how the policy is met in your environment, naming the systems, the roles and the steps. An SOP goes narrower still: a repeatable task written so anyone competent can perform it identically, which is what you want for joiners and leavers, restore tests, access reviews and incident triage. The distinction matters for a practical reason rather than a pedantic one.

Organisations that collapse all three into one document end up with a policy so detailed it is wrong the moment a system changes, and so long that nobody reads it, which is the fastest route to a control that exists on paper and nowhere else. Keep the policy stable, let the procedure move with the environment, and keep the SOP where the person doing the work will actually find it.

Why do off-the-shelf template packs fail?

Because they solve the wrong part of the problem. You download a zip of thirty Word documents for a few hundred pounds, and every one of them needs your systems, your roles, your sector and your framework threaded through it. The pack promised to save you weeks and instead hands you a fortnight of rewriting, which is why so many sit half-finished with the placeholders still in them.

A generic policy that describes systems you do not run and omits the ones you do is not evidence. It is a liability with your logo on it, and an assessor reading it will reach that conclusion faster than you would like.

The second failure is decay. Most template packs are out of date within a year, which is precisely the window in which your next audit, renewal or customer questionnaire lands. You migrate to a new firewall, adopt Intune, change backup provider or bring on a new SaaS platform, and every document referencing the old arrangement is now wrong.

Fixing that manually means hunting through thirty documents for every stale reference, which nobody does, so instead the pack quietly becomes fiction. Generating the pack around your real context, and regenerating it when the context changes, removes both problems at once: it fits from day one, and keeping it true is a task measured in minutes rather than weekends.

What is policy-reality drift, and how do you catch it?

It is the gap between what your documents say you do and what your systems are actually configured to do, and it is the single most common finding when we assess an organisation that considers itself compliant. The pattern is always the same. The policy says access is reviewed quarterly and the last review was fourteen months ago.

It says multi-factor authentication is enforced on all accounts, and it is enforced on all accounts except three service accounts and a shared mailbox somebody excepted during a rollout. It says backups are tested, and nobody can produce a record of a test. None of these are dishonesty. They are what happens when documents and reality are maintained by different people on different timescales.

Drift is caught by checking, and by checking on a schedule rather than when something prompts it. The useful mechanism is an internal audit that samples the actual state of controls against what the documents claim, produces a prioritised list of differences, and forces an explicit decision on each one: fix the reality, or change the document because the documented control was never realistic.

Both are legitimate outcomes. What is not legitimate is leaving the two apart, because the moment an assessor or a customer's security team compares them, your paperwork has become evidence against you rather than for you.

What evidence do assessors and customers actually ask for?

Almost none of this is difficult to produce as it happens, and almost all of it is painful to reconstruct afterwards.

This is where most organisations are genuinely weakest, because evidence lives scattered across inboxes, shared drives and half a dozen admin consoles rather than anywhere a person could assemble it from. The result is a familiar scramble: the week before the audit, someone spends three days screenshotting admin portals to prove things that were true all along.

The same problem shows up commercially when a prospect sends a two-hundred-line security questionnaire that is now blocking a deal, and the answers exist only in the heads of two people who are busy. Deciding in advance where the evidence for each control lives, and who owns producing it, compresses that from weeks into an afternoon.

How does an internal audit actually work?

You test your own controls against your own documented requirements, before someone external does it for you. In practice that means working through the framework control by control, asking what the documents say should happen, gathering the evidence that it did happen, and recording the difference where it did not.

The output is a prioritised, plain-English list of what to fix first, ranked by exposure rather than by how easy each item is. Doing it yourself in an afternoon rather than waiting a week for a consultant's report is the difference between an internal audit being a routine and being an event.

The worst time to discover a gap is when someone else finds it: an assessor mid-certification, an insurer at renewal, or a prospect three questions into a security questionnaire. Two disciplines make the exercise worth the time. First, audit against evidence rather than against memory, because asking whether you do something reliably produces the answer yes.

Second, close the loop: every finding needs an owner, a date and a record that it was actually resolved, because an audit that produces findings nobody tracks has generated paperwork rather than improvement. For ISO 27001 specifically the internal audit programme is not optional, it is part of what the certificate is awarded for.

Where does this fit on a Cyber Essentials journey?

Cyber Essentials is a self-assessment across five control themes, firewalls, secure configuration, security update management, user access control and malware protection, verified by an accredited certification body that reviews your answers.

Nobody logs into your systems to confirm what you have said is true, which makes the documentation and evidence behind your answers the thing worth getting right, because you are certifying that a state of affairs exists. The requirements that most often catch applicants out are that all software in scope must remain within vendor support, and that critical and high-severity updates are applied within fourteen days.

It must be completed within three months of achieving the base certificate, so the two are best planned as one sequence. Systech is an accredited Cyber Essentials provider and holds the certification itself, and our security team closes the technical gaps rather than only documenting them.

Where does this fit on an ISO 27001 journey?

ISO 27001 is a meaningfully bigger undertaking, because it certifies an Information Security Management System rather than a checklist of technical controls. The management system is the risk assessment methodology, the Statement of Applicability, the documented policies, the internal audit programme and regular management review.

You do not implement all 93 automatically: the Statement of Applicability is where you record, control by control, which apply to your scope and why any are excluded, and it is one of the first documents a Stage 1 auditor scrutinises.

Certification runs in two stages and then recurs. Stage 1 is a documentation review asking whether the management system exists on paper and whether the scope and exclusions are justified. Stage 2 asks whether it actually operates as documented, with evidence, internal audits that have genuinely happened, management reviews that have genuinely taken place and corrective actions that were tracked. Then it becomes a three-year cycle: lighter surveillance audits in years two and three, and full recertification before the three years are up.

Passing first time is almost always a preparation problem rather than a security problem, which is why organisations with sound technical controls still fail Stage 1. Systech holds ISO 27001 and ISO 9001, both certified by NDC Certification Services, so this is a cycle we run ourselves rather than only advise on, and we coordinate with an accredited certification partner for the formal audit rather than pretending to be one.

What cannot be outsourced, whatever you buy?

Accountability, and the decisions that carry it. A policy is a statement of what your organisation has decided, so someone in your organisation has to make and own that decision: whether personal devices may access company data, how long records are retained, who approves administrative access, what happens to data when someone leaves.

Under UK GDPR you remain the data controller regardless of who administers the systems, and no supplier arrangement changes who a regulator, an insurer or a customer holds responsible. We can generate the documents, run the assessment, fix the technical controls and stand beside you at the audit. We cannot be the accountable owner.

The practical version of this is that every policy needs a named internal owner who understands what it commits the business to, and that at least one person internally has to be able to answer questions about it without reading from the page.

Assessors notice when nobody can. It is also why we would rather generate a shorter pack that reflects your actual operating model than a comprehensive one describing an organisation you are not, because the second kind produces confident documents and an internal team who cannot explain them.

What does maintaining the pack look like after you are certified?

It becomes a cycle rather than a project, and the cycle is where certificates are actually lost. An ISMS allowed to lapse quietly between surveillance visits is the most common way organisations lose a certificate they worked hard to earn: the internal audits stop happening, management reviews slip, and the evidence trail the next auditor asks for simply is not there.

Cyber Essentials has its own version of the same problem, since it is verified annually and the question set is revised periodically, so answers that passed two years ago may not pass now.

Maintaining it properly means a review cadence for the documents, an internal audit schedule that actually runs, evidence captured as it is produced rather than assembled retrospectively, and a trigger to regenerate affected documents whenever the environment changes materially: a new platform, a new supplier, a migration, an office move, a significant change in headcount.

That last trigger is the one that keeps the pack honest, because environments change far more often than review dates come round. The practical benefit is that the next audit, renewal or customer questionnaire becomes a formality rather than a fire drill, which is the entire point of the exercise.

Where does the platform stop and hands-on work start?

Generating a policy does not make you compliant, and we are not going to pretend otherwise. Documents are the evidence layer; real compliance also needs the controls behind them to be in place and working.

EtherAssist, the compliance platform from our partner EfficientEther, produces the policies, procedures, SOPs and audit evidence around your actual context and lets you run internal audits and self-assessments on demand, which handles the slowest and most painful part of the job. What it cannot do is enforce multi-factor authentication on the three accounts that were excepted, test-restore a backup that has never been restored, or close the hole in a Conditional Access policy.

That is where our security team takes over: interpreting the gaps the self-assessment surfaces, remediating the technical controls, and being in the room for the certification audit itself.

The division is deliberate and worth stating plainly when you are comparing suppliers, because a compliance offering that only produces documents leaves you with better paperwork and the same underlying risk, and a technical engagement with no evidence layer leaves you secure and unable to prove it. You generally need both, and they should be scoped together rather than bought from two suppliers who each assume the other did the difficult half.