This is a realistic preview of the €299 Tailored Evidence Setup. ExampleCo is fictional, but the tailoring depth, document structure, and operational guidance match the intended live offer.
If a buyer purchases the live offer, the full checklist, complete owner map, and fully tailored planning detail are delivered against their own intake answers.
This preview is intentionally concrete. It shows the kind of named folders, example evidence requests, ownership logic, and first-week actions a buyer would receive after completing the async intake.
You do not need to read the whole pack first. Start with these. Each one should create visible progress on day one.
A.12 Operations Security/cloud-audit-logs/aws-cloudtrail/A.9 Access Control/mfa-evidence/A.18 Compliance/customer-security-review-comms/A.5 Information Security Policies/current-version/04-ExampleCo-owner-assignment-map-sample.csvWhen these are done, move to 05-ExampleCo-next-step-plan.md for the next 4 weeks.
Shown in full because the visible room structure is one of the most persuasive parts of the €299 deliverable.
ExampleCo ISO 27001 Evidence Room/
├── A.5 Information Security Policies/
│ ├── information-security-policy/
│ ├── acceptable-use-policy/
│ └── current-version/
├── A.6 Organisation of Information Security/
│ ├── roles-and-responsibilities/
│ ├── contact-with-authorities/
│ └── mobile-device-policy/
├── A.7 Human Resource Security/
│ ├── screening-records/
│ ├── security-awareness-training/
│ └── termination-process/
├── A.8 Asset Management/
│ ├── asset-inventory/
│ └── data-classification/
├── A.9 Access Control/
│ ├── access-control-policy/
│ ├── user-access-reviews/
│ ├── mfa-evidence/
│ ├── privileged-access/
│ └── aws-iam/
├── A.10 Cryptography/
│ ├── encryption-policy/
│ └── key-management/
├── A.11 Physical and Environmental Security/
│ └── cloud-only-note/
├── A.12 Operations Security/
│ ├── change-management/
│ ├── backup-evidence/
│ ├── logging-and-monitoring/
│ ├── datadog-alerts/
│ └── cloud-audit-logs/
├── A.13 Communications Security/
│ ├── network-security/
│ └── information-transfer/
├── A.14 System Acquisition Development and Maintenance/
│ ├── secure-development-policy/
│ ├── code-review-evidence/
│ ├── github-audit-log/
│ └── test-data-protection/
├── A.15 Supplier Relationships/
│ ├── supplier-register/
│ └── supplier-assessments/
├── A.16 Information Security Incident Management/
│ ├── incident-response-plan/
│ ├── incident-log/
│ └── lessons-learned/
├── A.17 Business Continuity/
│ ├── business-continuity-plan/
│ └── disaster-recovery-test-evidence/
├── A.18 Compliance/
│ ├── legal-register/
│ ├── privacy-policy/
│ ├── gdpr-records/
│ └── customer-security-review-comms/
└── Management Review/
├── risk-assessments/
├── management-review-minutes/
└── internal-audit/
The live deliverable would contain the full checklist across all relevant Annex A domains. This preview shows representative rows covering policy, access, operations, development, suppliers, incidents, continuity, and compliance.
| Annex A | Control | Evidence required | Where to get it | What to save | Where to store | Priority | Owner |
|---|---|---|---|---|---|---|---|
| A.5.1 | Information security policy | Approved policy PDF or tracked draft | Existing policies/docs; current acceptable-use policy as anchor | PDF export + 5-line delta note | A.5 Information Security Policies/information-security-policy/ | High | Founder + CTO |
| A.5.10 | Acceptable use rules | Acceptable use policy + acknowledgement path | Existing acceptable-use doc; onboarding checklist | Current version PDF + screenshot of acknowledgement step | A.5 Information Security Policies/acceptable-use-policy/ | Medium | HR |
| A.6.1 | Security roles and responsibilities | Named ownership + escalation path | Team roles list; Slack channel; incident contact note | 1-page roles note + owner map export | A.6 Organisation of Information Security/roles-and-responsibilities/ | High | CTO |
| A.7.2 | Security awareness | Awareness proof (lightweight but real) | BambooHR onboarding; internal wiki | Screenshot/export showing onboarding includes security acknowledgement | A.7 Human Resource Security/security-awareness-training/ | Medium | HR |
| A.8.2 | Data classification | Simple classification note/matrix | Product docs; GDPR notes; data flow understanding | One-page matrix PDF | A.8 Asset Management/data-classification/ | High | Product/Ops |
| A.9.2 | Access reviews | Access review export/screenshot for key systems | AWS IAM; GitHub org; BambooHR | Export user list + note of who reviewed and date | A.9 Access Control/user-access-reviews/ | High | CTO |
| A.9.4 | MFA enforcement | Proof MFA enabled for admins/sensitive systems | AWS root/admin; GitHub org settings | Screenshots of MFA settings + org policy | A.9 Access Control/mfa-evidence/ | High | CTO |
| A.9.5 | Privileged access control | List privileged accounts + review trail | AWS admin roles; emergency access accounts | Table of admin roles + screenshot/export | A.9 Access Control/privileged-access/ | High | CTO |
| A.12.4 | Logging and monitoring | Logging/monitoring posture evidence | Datadog; CloudTrail; key service logs | Screenshot of alert rules + one representative log export | A.12 Operations Security/logging-and-monitoring/ | High | DevOps |
| A.12.6 | Backup evidence | Backup configuration + retention proof | AWS backup settings; database backups | Screenshots + short restore assumption note | A.12 Operations Security/backup-evidence/ | Medium | DevOps |
| A.12.1 | Change management | Change approval/release history evidence | GitHub PRs; Linear tickets | Screenshots/export of PR review + linked tickets | A.12 Operations Security/change-management/ | High | CTO |
| A.14.2 | Secure development | PR review + branch protection evidence | GitHub org + repo settings | Branch protection screenshot + example reviewed PR link | A.14 System Acquisition Development and Maintenance/code-review-evidence/ | High | CTO |
| A.14.3 | Test-data protection | Non-prod data handling note | Dev practices; staging setup | 1-page note: do we copy prod data? if yes, controls | A.14 System Acquisition Development and Maintenance/test-data-protection/ | Medium | CTO |
| A.15.1 | Supplier management | Supplier register with risk note | Invoices; SSO app list; team knowledge | Supplier register v1 (top 10 critical vendors) | A.15 Supplier Relationships/supplier-register/ | High | Ops |
| A.16.1 | Incident response | Incident plan + incident log location | Internal wiki; ticketing tool | 1-page plan + empty incident log template | A.16 Information Security Incident Management/incident-response-plan/ | Medium | CTO |
| A.17.1 | Business continuity | Backup/recovery evidence and assumptions | AWS recovery posture; runbook notes | Short restore assumption note + one backup proof artifact | A.17 Business Continuity/disaster-recovery-test-evidence/ | Medium | DevOps |
| A.18.1 | Compliance obligations | Obligations register (GDPR/contracts) | Ireland + GDPR; customer contract asks | Top 5 obligations list + quarterly review owner | A.18 Compliance/legal-register/ | High | Founder |
This room is the working home for ExampleCo's ISO 27001 evidence. It was prepared for a live enterprise customer review and is designed to help a 15-person SaaS team collect, store, and review evidence without guessing where things belong.
Use YYYY-MM-DD_short-description.
Examples:
- 2026-05-01_aws-cloudtrail-enabled.png
- 2026-05-03_github-branch-protection.pdf
- 2026-05-05_supplier-register-v1.xlsx
Good enough evidence that is findable beats perfect evidence that lives in someone's inbox.
The live version would map the whole evidence set. This preview shows representative rows so buyers can see how responsibilities are made explicit.
| Evidence area | Annex domain | Accountable | Responsible | Backup | Frequency | First 30 min | First week | Notes |
|---|---|---|---|---|---|---|---|---|
| Policy set | A.5 | Founder | Founder | CTO | Quarterly | Find current policies and export PDFs | Mark review-existing vs create-new in the checklist | Keep scope tied to the onboarding SaaS product |
| Security roles and governance | A.6 | CTO | CTO | Founder | Quarterly | Name security lead + escalation path | Store the owner map export and comms channel note | One named owner beats a committee |
| People and onboarding evidence | A.7 | HR | HR | Founder | Quarterly | Locate onboarding security acknowledgement | Capture screenshot/export proving onboarding includes security | Keep proof lightweight but real |
| Asset and data inventory | A.8 | Product/Ops | Product/Ops | CTO | Monthly | Draft 1-page data classification note | Save matrix PDF and list top assets/systems | Separate customer vs employee data clearly |
| Access reviews | A.9 | CTO | DevOps | CTO | Monthly | Export AWS IAM + GitHub user lists | Run first access review and record date/outcome | High-signal customer-review evidence |
| Operations security | A.12 | DevOps | DevOps | CTO | Monthly | Capture CloudTrail + Datadog proof | Save backup configuration evidence and a restore assumption note | Keep first pass grounded in current reality |
| Supplier management | A.15 | Ops | Ops | Finance | Quarterly | Start supplier register with top vendors | Add owner + renewal month + risk note for each | Most audits stall here because it is “nobody's job” |
| Incident response | A.16 | CTO | CTO | Founder | Quarterly | Create incident log location | Write 1-page incident response note and store it | Do not overbuild yet |
| Compliance obligations | A.18 | Founder | Founder | CTO | Quarterly | List top 5 obligations (GDPR/contracts/customer asks) | Set a quarterly review cadence and owner | Tie obligations back to commercial pressure |
This plan is tailored to ExampleCo's intake: AWS hosting, GitHub + Datadog, and an enterprise customer review with a 3-month target.
By the end of Week 4, the evidence room should be usable by a reviewer without hand-holding: key exports/screenshots exist, ownership is named, and the checklist has real statuses and notes.
This document exists so ExampleCo knows what it is getting, and what it is not. It keeps the work crisp and stops the project turning into unbounded consulting.
If the deliverable does not match the stated intake use case, ComplianceClaw will revise it once at no extra charge. - Claim window: 14 days from delivery - Scope: alignment to intake and stated use case, not unlimited expansion
ExampleCo is an Ireland-based company handling customer and employee personal data. That means GDPR-linked evidence should stay visible, current, and easy to produce during customer reviews.
This pack is designed to remove first-pass structure and ownership guesswork. A consultant can build on it, but ExampleCo should not wait for a consultant before collecting the first evidence.
This pack is designed to remove guesswork, not replace every later phase of ISO 27001 work.
You are here. The room exists, the checklist is prioritised, and the immediate job is to collect evidence consistently.
Typical next documents include: - Information security policy - Access control policy - Incident response procedure - Business continuity plan - Risk assessment methodology - Supplier review note
ExampleCo already has a basic acceptable use policy, so the right move is to review and extend it, not start from zero everywhere.
Once the room is stable, turn the biggest obvious gaps into a formal risk view. This is where ISO 27001 stops being a filing exercise and starts shaping operating decisions.
Before any external review, test whether the evidence is easy to find, current, and actually supports the claim being made.
Keep the room alive with a simple rhythm: - Monthly: access reviews, backup checks, incident-log updates - Quarterly: management review, supplier review, risk refresh - Annually: policy review and internal audit prep
If the room is set up but policies, risk work, or internal audit preparation feel heavier than expected, that is usually the point where ongoing monthly support becomes useful.