+44 (0)1482 770583
hello@systechitsolutions.co.uk
This is for you if...
- You need a compliance pack for Cyber Essentials, ISO 27001, SOC 2, the DSP Toolkit or a customer's security questionnaire
- You've bought template packs before and drowned in documents that still needed rewriting
- You want to know what 'good' looks like before you spend another penny or another weekend on it
Most compliance packs fail not because a document is missing, but because nobody knew what the full set should be or where the evidence for each control was supposed to live. You find out during the audit, when an assessor asks for a register you've never created. Knowing the whole shape up front is the cheapest insurance there is.
What's inside
- The core documents every compliance pack needs: policies, procedures, SOPs and registers, grouped by control area
- What each document is actually for, in plain English, so you're not producing paperwork for its own sake
- Where the supporting evidence for each control lives, and who owns it
- The difference between a document that satisfies an assessor and one that just looks the part
- How to spot the gaps in your current pack before an auditor, insurer or prospect does
A compliance pack isn't a pile of documents, it's a set of controls, each with a policy that states your intent, a procedure or SOP that says how it's done, and evidence that proves it's actually happening. Off-the-shelf template packs hand you the documents and leave you to work out the rest. This is the map: what a complete pack contains, what each part is for, and where the evidence lives.
Use it two ways. If you're starting from nothing, it's the shopping list. If you already have a pack, run down it and mark what you're missing, most businesses find the gaps aren't policies at all, they're the registers and evidence nobody thought to create.
1. Governance & the top-level policy set
The documents that set the tone and satisfy the first questions any assessor or customer asks.
- Information Security Policy, your overarching statement of intent. Evidence: signed and dated by leadership, reviewed at least annually.
- Acceptable Use Policy, what staff can and can't do with company systems and data. Evidence: staff acknowledgement records.
- Roles & responsibilities, who owns security, who owns each control. Evidence: a named owner against every policy, not "IT".
- Risk register, your identified risks, their likelihood, impact and treatment. Evidence: dated entries with review notes, not a one-off snapshot.
2. Access & identity
- Access Control Policy plus a joiner/mover/leaver procedure. Evidence: a leavers register showing access was revoked, with dates.
- Multi-factor authentication standard, where MFA is enforced and how. Evidence: a configuration export, not a claim.
- Privileged access procedure, how admin rights are granted, reviewed and removed. Evidence: an admin account review log.
3. Devices & endpoints
- Device / endpoint management policy and an enrolment SOP. Evidence: an asset register mapped to enrolled, compliant devices.
- Patch management procedure, cadence, ownership, exceptions. Evidence: patch compliance reporting over time.
- Encryption and remote-wipe standard. Evidence: proof encryption is enforced and a wipe has been tested.
4. Data protection
- Data protection / privacy policy and a retention schedule. Evidence: a data map or Record of Processing Activities.
- Backup policy and a restore procedure. Evidence: a successful test-restore record, the single most-requested and least-produced artefact.
- Data classification / handling standard. Evidence: sensitivity labels or equivalent applied in practice.
5. Operations & resilience
- Incident response plan with defined roles and contacts. Evidence: a tabletop exercise or a real incident write-up.
- Business continuity / disaster recovery plan. Evidence: an RTO/RPO statement and the date it was last tested.
- Change management procedure. Evidence: a change log.
- Supplier / third-party security procedure. Evidence: a supplier register with their security status recorded.
6. People & the human layer
- Security awareness training procedure. Evidence: completion records and phishing-test results.
- Onboarding & offboarding SOPs that include security steps. Evidence: checklists completed per starter and leaver.
The pattern to notice
Read back through the list and the same shape repeats: a policy (intent), a procedure or SOP (method), and evidence (proof). Template packs are strong on the first, thin on the second, and silent on the third, which is precisely the order an assessor cares about in reverse. They want the evidence first, the procedure to explain it, and the policy to authorise it.
That's why "we bought a template pack" and "we're audit-ready" are rarely the same sentence. The documents are the easy 20%. The procedures written around your real systems, and the evidence that they're actually followed, are the 80% that decides whether you pass.
Where this leaves you
If this list showed you gaps, that's the point, better to find them here than in an audit. The slow way to close them is to write every document by hand and manually assemble the evidence. The fast way is to generate the policies, procedures and SOPs around your actual systems and framework, then run an internal audit that tells you exactly which evidence you're missing and who owns it. That's what Systech's Compliance Packs & Audit Readiness service does with EtherAssist, so the pack fits from day one and stays current, and our security team closes the technical gaps the self-audit surfaces.