Internal Audit Program

ISMS internal audit schedule and checklist

Public

Purpose

This program defines how Maelstrom AI conducts internal audits of the Information Security Management System (ISMS) to verify compliance with ISO 27001:2022 requirements and the effectiveness of security controls.

The ISMS covers Maelstrom AI as the organisation and both platforms it operates — Provii (zero-knowledge age verification) and downpipes (no-custody backup & disaster recovery for the Cloudflare data layer). Internal audit accordingly covers organisation-level processes and the technical controls of both products. Where a sampled control applies to downpipes, the auditor accounts for the no-custody operating-model boundary: the engine and console run in the customer’s own Cloudflare account under the customer’s keys (complementary user-entity controls), while Maelstrom operates the vendor-side control-plane and the signature-pinned update channel.

Audit Objectives

  • Verify ISMS implementation matches documented policies and procedures
  • Confirm effectiveness of security controls (Annex A)
  • Identify non-conformities and opportunities for improvement
  • Prepare for external certification audit
  • Ensure continuous improvement of security posture

Audit Scope

Covers all ISMS elements across both in-scope platforms (Provii and downpipes):

  • Policies and procedures
  • Risk management process
  • Implementation of 93 Annex A controls
  • Records and documentation
  • Operational effectiveness (including the complementary user-entity controls applicable to customer-operated downpipes instances)
  • Compliance with legal/regulatory requirements

Excludes:

  • External audits (certification body responsibility)
  • Supplier audits (separate process)

Audit Schedule

Annual Audit Plan

Full ISMS audit: Once per year (all clauses and controls) Focused audits: Quarterly (specific areas)

2026 Schedule:

  • Q1 2026 (Jan-Mar). ✅ Internal Audit #1 and #2 completed (February 2026)
  • Q2 2026 (Apr-Jun). Access control and cryptography
  • Q3 2026 (Jul-Sep). Change management and SDLC
  • Q4 2026 (Oct-Dec). Full ISMS audit (all clauses)

Flexibility: Schedule adjusted based on:

  • Significant changes to ISMS
  • New risks identified
  • Incidents requiring investigation
  • Management review outcomes

Audit Team

Roles

Lead Auditor / Auditee: Internal Auditor (sole operator)

  • Plans and conducts audits
  • Provides evidence and explains implementation
  • Reports findings in management review
  • Responds to and addresses findings

Note on independence: As a sole operator, full auditor independence is not achievable. Mitigations:

  • Objective checklists used (reduces subjectivity)
  • External certification audit will provide independent verification (when pursued)
  • Management review provides structured self-assessment
  • Findings documented transparently in public ISMS
  • Automated controls (CI/CD, Dependabot, SLSA) provide objective evidence

Audit Process

Phase 1: Planning (1 week before)

Activities:

  1. Review previous audit findings and corrective actions
  2. Review relevant ISMS documents
  3. Prepare audit checklist (see below)
  4. Schedule audit time block
  5. Notify team members of audit (when team grows)

Deliverable: Audit plan with scope, schedule, checklist

Phase 2: Execution (1-2 days)

Activities:

  1. Opening meeting (scope, objectives, process)
  2. Document review (policies, procedures, records)
  3. Review process implementation (interviews with process owners when team grows)
  4. Evidence sampling (logs, change records, access reviews)
  5. Observation of processes
  6. Note findings (conformities, non-conformities, opportunities)
  7. Closing meeting (preliminary findings)

Techniques:

  • Ask for evidence: “Show me the most recent access review”
  • Trace processes: “Walk me through how you respond to a security incident”
  • Sample records: Check 5 random changes for approval
  • Verify controls: Test MFA enforcement on critical systems

Phase 3: Reporting (1 week after)

Activities:

  1. Finalise findings
  2. Classify non-conformities (major, minor, observation)
  3. Write audit report
  4. Submit to ISMS Owner
  5. Present in management review

Report Contents:

  • Audit scope and dates
  • Auditors and auditees
  • Summary of findings
  • Detailed non-conformities
  • Opportunities for improvement
  • Conclusion (ISMS effectiveness)

Phase 4: Follow-up (Ongoing)

Activities:

  1. Auditee proposes corrective actions
  2. Lead Auditor reviews and approves
  3. Implement corrective actions (30-90 days)
  4. Verify effectiveness in next audit
  5. Close non-conformities

Audit Checklist

ISO 27001 Clause 4: Context of the Organisation

ItemEvidence RequiredStatus
4.1 Understanding the organisationContext Analysis reviewed
4.2 Interested parties identifiedDocumented in context analysis
4.3 ISMS scope definedISMS Scope current and appropriate

Clause 5: Leadership

ItemEvidence RequiredStatus
5.1 Leadership and commitmentManagement review records show engagement
5.2 Information security policyPolicy approved and communicated
5.3 Roles and responsibilitiesRoles matrix assigned and understood

Clause 6: Planning

ItemEvidence RequiredStatus
6.1.1 Risk assessment processRisk Methodology followed
6.1.2 Risk treatmentRisk Register current (within 3 months)
6.1.3 Information security objectivesObjectives documented and measured
6.2 Planning changesChange management records show planning

Clause 7: Support

ItemEvidence RequiredStatus
7.1 ResourcesAdequate resources allocated (staffing, budget, tools)
7.2 CompetenceCompetence record current; professional certifications maintained
7.3 AwarenessSecurity awareness maintained through certifications and industry engagement
7.4 CommunicationSecurity communications documented (approved channels, meetings)
7.5 Documented informationISMS documentation complete and version controlled

Clause 8: Operation

ItemEvidence RequiredStatus
8.1 Operational planningProcesses documented and followed
8.2 Risk assessmentQuarterly risk reviews completed
8.3 Risk treatmentTreatment plans implemented

Clause 9: Performance Evaluation

ItemEvidence RequiredStatus
9.1 Monitoring and measurementSecurity metrics tracked (incidents, vulnerabilities)
9.2 Internal auditPrevious audit completed, findings addressed
9.3 Management reviewQuarterly management review conducted

Clause 10: Improvement

ItemEvidence RequiredStatus
10.1 Nonconformity and corrective actionNon-conformities documented and corrected
10.2 Continual improvementEvidence of ISMS improvements over time

Annex A Controls Sampling

Full audit (annual): Review all 93 controls Focused audits (quarterly): Sample 10-15 controls

Selection criteria:

  • High-risk controls (cryptography, access control)
  • Controls with previous non-conformities
  • Controls recently implemented
  • Random sampling for coverage

Sample Control Audit Questions

A.5.1 Policies for Information Security:

  • Show me the current Information Security Policy
  • When was it last reviewed?
  • Evidence of acknowledgment? (team members when applicable)

A.5.15 Access Control:

  • Show me the list of GitHub organisation members
  • Show me the list of Cloudflare account users
  • When was the last access review?
  • How is MFA enforced?

A.8.9 Configuration Management:

  • Show me the wrangler.toml for production (Provii Workers; the downpipes vendor-side control-plane and update channel)
  • How are changes to configuration controlled?
  • Evidence of configuration review?
  • For downpipes, how is the routeless in-tenant engine configured, and the 51 zone/account configuration surfaces it backs up enumerated?

A.5.24 Incident Management:

  • Show me incident response procedure
  • Show me records of last incident (or test/drill)
  • How quickly are incidents detected and responded to?

A.8.3 Cryptographic Controls:

  • Show me approved cryptographic algorithms (Provii ZK stack; downpipes post-quantum hybrid sealing)
  • Where are signing keys stored? (Provii signing keys; the downpipes Licence Signer in Cloudflare Secrets Store; the downpipes Update Signer held offline by the operator, never deployed to any Worker)
  • For downpipes, confirm archive-sealing keys are customer-held (no-custody): Maelstrom holds no customer keys, data or Cloudflare tokens
  • Evidence of key rotation schedule?

A.8.13 Information Backup:

  • Show me evidence that Maelstrom’s entire Cloudflare estate is backed up by our own production instance of downpipes (dogfooding)
  • Confirm the 3-2-1 fan-out to 2+ customer-controlled destinations and recent restore-test evidence
  • See Cloudflare Backup Evidence

Findings Classification

Major Non-Conformity

Definition: Absence or failure of control that could lead to serious security breach

Examples:

  • No access control policy
  • Signing keys stored in plaintext
  • No incident response capability
  • Critical risk unaddressed

Response: Immediate corrective action required (30 days maximum)

Minor Non-Conformity

Definition: Isolated lapse or incomplete implementation

Examples:

  • Access review 2 weeks late
  • Documentation outdated
  • Certification renewal overdue
  • Control implemented but not documented

Response: Corrective action required (90 days)

Observation

Definition: Not a non-conformity, but could become one or could be improved

Examples:

  • Process works but is inefficient
  • Documentation could be clearer
  • Best practice not followed (but meets standard)
  • Potential future risk

Response: Consider for improvement (no deadline)


Corrective Actions

Process:

  1. Auditor documents finding in report
  2. Auditee proposes corrective action plan (within 14 days)
  3. Plan includes:
  • Root cause analysis
  • Corrective action description
  • Responsible person
  • Target completion date
  • Preventive measures
  1. Lead Auditor approves plan
  2. Auditee implements
  3. Lead Auditor verifies effectiveness (next audit or specific check)
  4. Finding closed

Tracking: Maintained in corrective action register (simple spreadsheet or issue tracker)


Audit Records

Maintained for each audit:

  • Audit plan
  • Audit checklist (completed)
  • Evidence reviewed (list of documents, screenshots, etc.)
  • Interview notes
  • Audit report
  • Corrective action plans
  • Follow-up verification

Retention: 3 years (for certification maintenance)

Storage: Secure location (Google Drive folder with restricted access)


Audit History

Internal Audit #1 and #2 (February 2026)

First audit cycle completed. Two audits conducted covering documentation completeness, operational evidence, and control implementation.

Key outcomes:

  • 7 operational evidence records created (management review, access review, incident register, DSAR register, competence, internal audit, key rotation log)
  • Findings fed into Management Review #1 (15 February 2026)
  • Corrective actions tracked in Planned Work Register (maintained internally; available to auditors and enterprise customers on request)

Lessons from first audit:

  • Documentation foundation was solid (established Jan 2025)
  • Operational execution gaps identified (risk assessment, supplier review, incident response testing)
  • Forward-looking claims required significant cleanup (45 aspirational items removed or softened)
  • Sole operator context requires adapted audit approach

Continuous Improvement

After each audit:

  • Review audit process effectiveness
  • Update checklist based on findings
  • Adjust audit schedule if needed
  • Share lessons learned (with team when applicable)
  • Record what’s working well

Metrics:

  • Number of findings (trend over time - should decrease)
  • Time to close corrective actions
  • Repeat findings (should be zero)
  • ISMS maturity increasing

  1. Statement of Applicability - Controls to audit
  2. Management Review - Audit results reviewed
  3. Evidence Collection Checklist - What to collect

Document Information

  • Version. 2.1
  • Effective Date. 2025-01-13 (initial), 2026-02-16 (updated)
  • Last Updated. 2026-06-19
  • Owner. ISMS Owner
  • Review Frequency. Annually
  • Next Review. 2027-02-15
  • Classification. Public
  • Change (2.1). downpipes added as second in-scope platform; the legacy backup worker retired in favour of self-hosted downpipes.