Purpose
This checklist helps prepare evidence for internal audits and external ISO 27001 certification audits. It identifies what records to collect, where to find them, and how to organise them.
The ISMS covers Maelstrom AI as the organisation, operating two platforms under one team and one ISMS — Provii (zero-knowledge age verification) and downpipes (no-custody backup & disaster recovery for the Cloudflare data layer). Collect evidence for both platforms. Where a control is organisation-level (governance, access control, change management, supplier management) the same record covers both; where it is product-specific (cryptography, infrastructure, backup), gather evidence for each platform, noting the no-custody operating-model boundary for downpipes — the engine and console run in the customer’s own Cloudflare account, under the customer’s keys (a complementary user-entity control), so the customer-operated instances are out of Maelstrom’s direct evidence reach.
Use this checklist:
- 4 weeks before internal audit
- 8 weeks before external certification audit
- Continuously (collect evidence as you go)
General Principles
Evidence Types
Documentary Evidence: Policies, procedures, records Physical Evidence: Configurations, system settings (screenshots) Testimonial Evidence: Interviews, explanations (during audit)
Quality of Evidence
Good evidence is:
- Relevant. Directly demonstrates control implementation
- Current. Recent enough to show ongoing compliance
- Complete. Shows the full process, not just one instance
- Objective. Factual records, not just assertions
Evidence Organisation
Recommended structure:
Audit-Evidence-YYYY-MM/
├── 01-Policies/
├── 02-Risk-Management/
├── 03-Operational-Security/
├── 04-Access-Control/
├── 05-Cryptography/
├── 06-SDLC-Security/
├── 07-Incident-Response/
├── 08-Records/
└── README.md (index of all evidence)Clause 4: Context of the Organisation
| Evidence Item | Location | Date Range | Responsible |
|---|---|---|---|
| 4.1-4.2: Context Analysis | /security/context-analysis | Current version | ISMS Owner |
| 4.3: ISMS Scope | /security/isms-scope | Current version | ISMS Owner |
| Approval records | Git commit history | Latest approval | ISMS Owner |
Action: Export latest versions as PDF, include git log showing last review date.
Clause 5: Leadership
| Evidence Item | Location | Date Range | Responsible |
|---|---|---|---|
| 5.1: Management commitment | Management review minutes | Last 12 months | ISMS Owner |
| 5.2: Information Security Policy | /security/information-security-policy | Current version | ISMS Owner |
| Policy approval | Git commit history | Latest version | ISMS Owner |
| 5.3: Roles and Responsibilities | /security/roles-responsibilities | Current version | ISMS Owner |
| Role assignments | Team roster, access lists | Current | Security Lead |
Action: Show management review minutes demonstrating leadership engagement. Export policy with approval date.
Clause 6: Planning
| Evidence Item | Location | Date Range | Responsible |
|---|---|---|---|
| 6.1.1: Risk assessment process | /security/risk-methodology | Current version | Security Lead |
| 6.1.2: Risk treatment | /security/risk-register | Last 3 months | Security Lead |
| Risk assessment records | Risk register updates | Quarterly | Security Lead |
| 6.1.3: Information security objectives | Information Security Policy | Current version | ISMS Owner |
| Objectives measurement | Metrics reports (incidents, vulnerabilities) | Last 12 months | Security Lead |
| 6.2: Planning changes | Change management records (PRs, deployment logs) | Last 3 months | Security Lead |
Action: Show risk register is current (updated within last 3 months). Demonstrate objectives are measured (metrics).
Clause 7: Support
| Evidence Item | Location | Date Range | Responsible |
|---|---|---|---|
| 7.1: Resources | Budget allocation, staffing plan | Current year | ISMS Owner |
| Security tools | List of tools (GitHub, Cloudflare, password manager) | Current | Security Lead |
| 7.2: Competence | Training records | All current team + last 12 months | Security Lead |
| Competence requirements | Roles & Responsibilities | Current | ISMS Owner |
| 7.3: Awareness | Training completion records | Last 12 months | Security Lead |
| Policy acknowledgements | Signed acknowledgement forms | All current team | Security Lead |
| 7.4: Communication | Security communications (Signal, email, meetings) | Last 3 months | Security Lead |
| 7.5: Documented information | ISMS documentation (all pages) | Current versions | Security Lead |
| Document control | Git commit history (version control) | Last 12 months | Security Lead |
Action:
- Collect training completion records (who, when, topic)
- Screenshot GitHub org members (demonstrates resourcing)
- Export ISMS documentation with version history
Clause 8: Operation
| Evidence Item | Location | Date Range | Responsible |
|---|---|---|---|
| 8.1: Operational planning | Procedures documented in ISMS | Current versions | Security Lead |
| 8.2: Risk assessment | Quarterly risk assessment records | Last 12 months | Security Lead |
| 8.3: Risk treatment | Risk treatment implementation evidence | Ongoing | Security Lead |
Action: Show procedures are followed (sample 5 changes, verify they followed change management process).
Clause 9: Performance Evaluation
| Evidence Item | Location | Date Range | Responsible |
|---|---|---|---|
| 9.1: Monitoring and measurement | Security metrics reports | Last 12 months | Security Lead |
| Incident logs | Incident response records | Last 12 months | Security Lead |
| Vulnerability scans | GitHub security alerts, Dependabot | Last 3 months | Security Lead |
| 9.2: Internal audit | Internal audit report | Last audit | Internal Auditor |
| Audit checklist (completed) | Audit records | Last audit | Security Lead |
| Corrective action records | Action tracker | Since last audit | Security Lead |
| 9.3: Management review | Management review minutes | Last review | ISMS Owner |
| Management review inputs | Metrics, audit results, risk register | Last review | Security Lead |
Action:
- Compile security metrics (incidents, vulnerabilities, training)
- Include completed internal audit report with findings and corrective actions
- Include management review minutes
Clause 10: Improvement
| Evidence Item | Location | Date Range | Responsible |
|---|---|---|---|
| 10.1: Nonconformity and corrective action | Corrective action register | Last 12 months | Security Lead |
| Corrective action effectiveness | Follow-up verification records | Since actions implemented | Security Lead |
| 10.2: Continual improvement | ISMS updates, control improvements | Last 12 months | Security Lead |
| Improvement log | Management review, retrospectives | Last 12 months | ISMS Owner |
Action: Show examples of improvements made (e.g., SOA controls moving from “Planned” to “Implemented”).
Annex A Controls: Selected Examples
A.5.1: Policies for Information Security
| Evidence | Location |
|---|---|
| Information Security Policy | /security/information-security-policy |
| Policy approval | Git commit (date, approver) |
| Policy communication | Training records (all staff read policy) |
A.5.15: Access Control
| Evidence | Location |
|---|---|
| Access Control Policy | /security/access-control |
| Access lists | GitHub org members, Cloudflare users (screenshot) |
| Access review records | Quarterly review spreadsheet/log |
| MFA enforcement | Screenshots showing MFA required on GitHub, Cloudflare |
| Provisioning/revocation logs | GitHub audit log, onboarding/offboarding checklists |
Action: Screenshot GitHub “People” page showing MFA status. Export Cloudflare user list. Provide last access review.
A.5.24: Incident Management Planning and Preparation
| Evidence | Location |
|---|---|
| Incident Response procedure | /security/incident-response |
| Incident records | Incident log (last 12 months) |
| Incident postmortems | Completed postmortems (if incidents occurred) |
| Contact information | security@maelstrom.au documented |
| Test/drill records | Tabletop exercise or real incident response |
Action: If no real incidents, document a tabletop exercise (simulated incident, how we’d respond).
A.5.31: Legal, Statutory, Regulatory and Contractual Requirements
| Evidence | Location |
|---|---|
| Compliance register | Australian Privacy Act, ISO 27001 (documented in context analysis) |
| Privacy compliance (Provii) | Zero-knowledge architecture (date of birth processed ephemerally at issuance; no PII persisted server-side; verification collects no PII) |
| Privacy compliance (downpipes) | No-custody architecture — Maelstrom holds no customer keys, data or Cloudflare tokens; backups run in the customer’s own Cloudflare account under the customer’s keys, so Maelstrom adds no sub-processor for customer backup data |
| Supplier contracts | Cloudflare, GitHub agreements (data processing addendum) |
Action: Export Cloudflare/GitHub contract terms. Document the zero knowledge architecture (Provii) and the no-custody architecture (downpipes) as the privacy compliance strategy.
A.8.3: Management of Technical Vulnerabilities
| Evidence | Location |
|---|---|
| Vulnerability management process | Dependabot, cargo audit, npm audit (in CI/CD) |
| Vulnerability scan results | GitHub security alerts, Dependabot PRs |
| Patch records | PRs addressing vulnerabilities (timestamps show <24hr for critical) |
Action: Screenshot GitHub security overview (vulnerabilities, Dependabot). Export sample vulnerability → patch → merge timeline.
A.8.9: Configuration Management
| Evidence | Location |
|---|---|
| Configuration management procedure | Git-based configuration (wrangler.toml, CI/CD) |
| Configuration baselines | wrangler.toml in Git (versioned) |
| Configuration change control | PRs for configuration changes (review required) |
Action: Show wrangler.toml in Git. Show sample PR changing configuration (review, approval, CI).
A.8.23: Web Filtering
Status: Not Applicable (no corporate network)
Evidence: N/A justification documented in SOA
A.8.24: Use of Cryptography
| Evidence | Location |
|---|---|
| Cryptography Policy | /security/cryptography-policy |
| Approved algorithms (Provii) | Groth16, RedJubjub, BLAKE2, HMAC-SHA256 documented |
| Approved algorithms (downpipes) | Post-quantum hybrid archive sealing documented in Cryptography Policy |
| Key management procedure | Key generation, storage, rotation documented |
| Key rotation records | Audit log of key rotations |
| JWKS | Public verification keys published |
| downpipes vendor-side signers | Asset Register CRYPTO-008 (Licence Signer), CRYPTO-009 (Update Signer, held offline) |
Action: Export cryptography policy. Show JWKS (public keys). Provide audit log entry for last key rotation. For downpipes, show that archives are sealed under customer-held keys (no-custody — Maelstrom holds no customer encryption keys); evidence the two vendor-side signers only (Licence Signer, offline Update Signer).
Operational Evidence
Secure Development Lifecycle
| Evidence | Location |
|---|---|
| Secure coding guidelines | Cryptography Policy, Security Awareness |
| Code review requirement | Branch protection rules (screenshot) |
| Security scanning | CI/CD workflow files (.github/workflows/) |
| Security scan results | Recent CI/CD runs (passing scans) |
| SLSA compliance | Provenance attestations on GitHub releases |
| downpipes update channel integrity | Signature-pinned, pull-only update channel (updates.downpipes.io); engines verify each update against a pinned public key before applying; signing performed offline by the operator with the Update Signer (never deployed to any Worker) |
Action:
- Screenshot GitHub branch protection (require review, passing CI)
- Export CI workflow files (show CodeQL, cargo audit, npm audit)
- Show SLSA provenance on a recent release
- For downpipes, show a signed, signature-pinned update artefact and evidence the offline-held Update Signer
Logging and Monitoring
| Evidence | Location |
|---|---|
| Logging policy | Data Retention Policy |
| Audit logs | Cloudflare Workers Logs (Grafana Loki), KV audit logs (sample) |
| Log retention | 90 days (audit logs, including IP addresses) documented; critical security event logs are retained for up to 365 days |
| Log review | Evidence of logs reviewed (incident investigations, or periodic review) |
| downpipes self-monitoring | Scored security posture with regression alerts, hourly canary integrity flights, operator-paging notification rules (the engine runs dark — no standing inbound vendor path) |
| downpipes consent diagnostics | Redaction-safe signed support bundle plus owner-minted, time-boxed, scoped, immediately-revocable read-only pull credentials (no standing vendor access) |
Action: Screenshot Grafana Loki dashboard for the Workers Logs sink. Provide sample audit log entry (redacted if needed). For downpipes, show the security-posture report and canary-flight evidence, and document the consent-diagnostics model (no standing vendor access).
Business Continuity
| Evidence | Location |
|---|---|
| Business Continuity Plan | /security/business-continuity |
| Backup strategy | Signing key backups, Git backups documented |
| Cloudflare data-layer backup | Maelstrom’s entire Cloudflare estate is backed up by our own production instance of downpipes (3-2-1 fan-out, post-quantum sealed under operator-held keys) — see Cloudflare Backup Evidence |
| RTO/RPO defined | Documented for each service (Provii services and the vendor-operated downpipes control-plane and update channel) |
| DR test | Evidence of testing (real incident or tabletop); hourly canary integrity flights and scheduled in-account restore drills from the dogfooded downpipes instance |
Action: Document last incident that tested BC plan (or conduct tabletop exercise). Provide the dogfooded downpipes restore-drill and canary-flight reports as continuous backup-verification evidence.
Supplier Management
| Evidence | Location |
|---|---|
| Supplier Management procedure | /security/supplier-management |
| Critical supplier list | Cloudflare, GitHub documented |
| Supplier risk assessments | Documented in supplier management |
| Supplier contracts | Cloudflare, GitHub ToS + DPA |
| Supplier monitoring | Status page checks, security advisories reviewed |
| downpipes sub-processors | None added for customer data — downpipes is no-custody (runs in the customer’s own Cloudflare account under the customer’s keys), so Maelstrom introduces no sub-processor for customer backup data |
Action: Export supplier contracts. Screenshot Cloudflare/GitHub status pages (monitoring evidence).
Records to Maintain Ongoing
Access Control
- GitHub organisation members list (quarterly)
- Cloudflare account users list (quarterly)
- Access review completion records (quarterly)
- Onboarding checklists (per hire)
- Offboarding checklists (per departure)
Training
- Training completion records (per person, per training)
- Training acknowledgement forms
- Training content (slides, videos, documentation links)
Risk Management
- Risk assessment records (quarterly)
- Risk register updates (quarterly)
- Risk treatment plans (per risk)
Incident Response
- Incident reports (per incident)
- Incident postmortems (per P0/P1 incident)
- Incident log (all incidents)
Change Management
- Pull requests (all changes)
- Deployment logs (wrangler CLI output, GitHub Actions)
- Emergency change log (if any emergency changes)
Cryptography
- Key generation ceremonies (per key)
- Key rotation records (annually)
- JWKS updates (per rotation)
- Key status transitions (Active → Deprecated → Disabled)
- downpipes vendor-side signer records (Licence Signer, offline Update Signer) — customer-held downpipes encryption keys are no-custody and are not Maelstrom records
Audits
- Internal audit reports (annually)
- Corrective action register (ongoing)
- Management review minutes (quarterly)
Evidence Sources
GitHub
What to export:
- Organisation settings (screenshot: MFA required, members, teams)
- Branch protection rules (screenshot)
- Security overview (vulnerabilities, Dependabot)
- Recent pull requests (showing code review, CI passing)
- GitHub Actions workflow files (CI/CD)
- GitHub Actions run logs (security scans passing)
- Audit log (access provisioning/revocation)
How:
- GitHub UI → Organisation Settings → Security & Analysis
- GitHub UI → Repository → Insights → Security
git logfor commit history
Cloudflare
What to export:
- Account users (screenshot)
- Workers deployments (wrangler CLI logs) — Provii Workers and the vendor-operated downpipes control-plane; the dogfooded downpipes engine/console run in Maelstrom’s own account
- KV namespaces (list, not contents)
- Analytics (uptime, traffic)
- Security events (if any)
How:
- Cloudflare Dashboard → Account → Members
wrangler whoami(authentication)- Cloudflare Dashboard → Analytics
downpipes (customer-operated). A downpipes customer’s engine and console run in the customer’s own Cloudflare account under the customer’s keys (a complementary user-entity control), so those running instances are not part of Maelstrom’s Cloudflare account export. Maelstrom evidences the software it builds, the vendor-operated control-plane and update channel, and its own dogfooded production instance.
Local Systems
What to export:
- Training records (spreadsheet: who, what, when, status)
- Incident log (spreadsheet or issue tracker)
- Risk register (current version from docs)
- Management review minutes (document)
- Internal audit report (document)
How:
- Maintain in Google Docs, GitHub Issues, or simple spreadsheet
- Export as PDF for audit
Audit Preparation Timeline
8 Weeks Before External Audit
- Review this checklist
- Identify gaps in evidence
- Start collecting missing evidence
- Update ISMS documentation (if outdated)
4 Weeks Before
- Complete evidence collection
- Organise evidence into folders
- Create evidence index (README)
- Conduct mock internal audit
- Address any findings from mock audit
2 Weeks Before
- Finalise evidence package
- Share evidence index with auditor (if pre-audit review)
- Prepare team for interviews
- Review ISMS documents (everyone knows where to find things)
1 Week Before
- Confirm evidence access (can auditor access GitHub, Cloudflare if needed?)
- Confirm audit logistics (date, time, attendees, agenda)
- Final check: all documents current
During Audit
- Provide evidence as requested
- Take notes on findings
- Ask questions if unclear
- Professional, honest, transparent
After Audit
- Review findings
- Develop corrective action plans
- Implement corrective actions
- Verify effectiveness
- Document lessons learned
Tips for Effective Evidence
Do:
- Keep evidence up-to-date (don’t scramble before audit)
- Organise evidence logically (auditor can find what they need)
- Use timestamps (show when actions occurred)
- Be honest (if something isn’t done, say so, don’t fabricate)
Don’t:
- Create evidence just for the audit (auditor will see through it)
- Provide more evidence than requested (stay focused)
- Hide weaknesses (auditor will find them anyway, honesty builds trust)
Related Documents
- Internal Audit Program - What auditors will check
- Statement of Applicability - All controls implemented
- Management Review - Quarterly review outputs
- ISMS Scope Statement - Two-platform scope and the downpipes operating-model boundary
- Cloudflare Backup Evidence - Self-hosted downpipes backup of Maelstrom’s Cloudflare estate
Document Information
- Version. 2.1
- Effective Date. 2025-01-13 (initial), 2026-06-19 (updated)
- Last Updated. 2026-06-19
- Owner. ISMS Owner
- Review Frequency. Annually (before audit)
- Next Review. 2027-01-13
- Classification. Public
- Change (2.1). downpipes added as second in-scope platform; the legacy backup worker retired in favour of self-hosted downpipes. Added downpipes evidence to the cross-cutting controls (cryptography, supply chain, infrastructure, logging/monitoring, business continuity, supplier management) and reframed the Cloudflare data-layer backup onto Maelstrom’s own production instance of downpipes (linking the renamed Cloudflare Backup Evidence).