Statement of Applicability (SOA)

Requirement: Information security policy and topic-specific policies defined, approved, published, communicated, and reviewed.

Implementation:

• Information Security Policy defined and approved by ISMS Owner
• Published transparently at maelstrom.au/trust
• Communicated to all team members
• Annual review schedule established

Evidence: Published policy documents, version control history, review dates

Requirement: Information security roles and responsibilities defined and allocated.

Implementation:

• ISMS Owner has overall accountability
• Security Lead responsible for implementation and maintenance
• Developers responsible for secure development
• All team members responsible for reporting incidents
• Documented in Information Security Policy
• See also: Roles and Responsibilities Matrix

Evidence: Role definitions in policy documents, job descriptions, incident reporting procedures

Requirement: Conflicting duties and areas of responsibility segregated to reduce opportunities for unauthorized modification or misuse.

Implementation: Full segregation not feasible for a sole operator; addressed through compensating controls:

Compensating Controls (detailed in Access Control Policy):

1. Mandatory code review: Self-review via pull request with passing CI status checks before merge, and a full audit trail. Two-person review is not feasible for a sole operator and is an accepted ISO 27001 A.5.3 limitation (see the risk register).
2. Sequential review: Critical operations (signing keys, production changes, security policies) require ISMS Owner sign-off documented in the change record before execution, plus post-execution independent audit log review
3. Audit logging: All privileged actions logged, reviewed weekly
4. Quarterly access reviews: Formal review by ISMS Owner
5. Annual third-party audits: Independent verification
6. Least privilege: Minimal access, scoped tokens
7. MFA enforcement: All privileged accounts
8. Open source transparency: Public code review

Segregation Matrix: Role-based permissions documented with specific ALLOWED/FORBIDDEN operations per role

Elevated-Risk Operations (require pre-execution change record and post-execution audit log review):

• Signing key generation/rotation
• Production database changes
• User data deletion
• Security policy changes
• Account-level infrastructure changes

Risk Acknowledgment: Single-operator bus-factor risk and residual segregation limitations formally accepted by ISMS Owner with quarterly re-evaluation. Recovery is addressed in the Business Continuity Plan.

Evidence: Access Control Policy, GitHub branch protection rules, change record logs, audit log review records, quarterly access review reports, role permission matrix

Requirement: Management require all personnel to apply information security in accordance with the established policies and procedures.

Implementation:

• ISMS Owner has overall accountability for information security
• Security considered in all management decisions
• Quarterly management review of ISMS effectiveness
• Personnel acknowledge security policies on joining

Evidence: Management review minutes, policy acknowledgment records

Requirement: Contacts with relevant authorities maintained as appropriate.

Implementation:

• security@maelstrom.au for vulnerability disclosure
• Established relationships: Cloudflare support, GitHub support
• Australian law enforcement contacts documented (private)
• Regulatory contacts for Privacy Act compliance

Evidence: Contact list (internal), email communications

Requirement: Contacts with security forums and professional associations maintained.

Implementation:

• Active in cryptography and ZKP communities
• Monitor rust-sec advisories
• GitHub Security Lab participation
• SLSA community engagement

Evidence: GitHub contributions, community forum participation

Requirement: Information relating to information security threats collected and analysed.

Implementation:

• GitHub Security Alerts (dependency vulnerabilities)
• Rust Security Advisory Database monitoring
• npm audit in CI/CD
• Cloudflare threat intelligence (automatic)
• Security mailing lists

Evidence: CI/CD security scan logs, vulnerability tracking

Docs gateway application: The docs sandbox gateway ingests Cloudflare bot scores, Cloudflare Bot Fight Mode challenge outcomes, and Super Bot Fight Mode signals for the docs.provii.app/api/* prefix. Cloudflare Bot Fight Mode challenge daily volume is alarmed at 500k/day via Cloudflare Notifications to surface credential-stuffing and automated-onboarding abuse.

Requirement: Information security integrated into project management.

Implementation:

• Security requirements in all new features
• Threat modelling before implementation
• Security testing in CI/CD
• Code review includes security review

Evidence: CI/CD workflows, code review comments, threat models

Requirement: Assets associated with information and information processing facilities identified and inventory maintained.

Implementation:

• Asset Register maintained
• Assets classified (Critical, High, Medium, Low)
• Owners assigned (by role)
• 15 repos in our GitHub organisation (6 Rust, 8 TypeScript, 1 mobile)
• Cloudflare Workers, KV namespaces, Durable Objects, R2 buckets inventoried

Evidence: Asset register document, quarterly reviews

Requirement: Rules for the acceptable use of information and assets identified, documented and implemented.

Implementation:

• Acceptable Use Policy defined
• Covers workstations, cloud access, credentials
• Acknowledged by all team members
• Violations reported and addressed

Evidence: Acceptable use policy, acknowledgment records

Docs gateway application: External developers onboarding through docs.provii.app/api/* accept use terms bound to the __Host-docs_session bearer. Sandbox credentials minted through the gateway are explicitly non-production and subject to a per-bearer lifetime cap of 3 verifier plus 3 issuer credentials, with quarterly rotation of the shared sandbox issuer identity.

Requirement: Personnel and external parties return all organisation assets upon change or termination of employment.

Implementation:

• Offboarding checklist includes:
• Revoke GitHub access
• Revoke Cloudflare access
• Remove from team communication channels
• Collect hardware (if company-provided)
• Access reviews verify cleanup

Evidence: Offboarding checklist, access audit logs

Requirement: Information classified according to legal requirements, value, criticality and sensitivity.

Implementation:

• Classification levels: Public, Internal, Confidential, Restricted
• Applied to all documents (see document metadata)
• Signing keys: Restricted
• Source code: Public (open source)
• Operational secrets: Restricted
• ISMS documentation: Public

Evidence: Document classifications in metadata

Requirement: Appropriate set of procedures for information labelling developed and implemented.

Implementation:

• Document metadata includes classification
• File naming conventions
• Secrets stored in designated locations (Cloudflare secrets, KV)
• Never in source code or logs

Evidence: Document templates, secret storage procedures

Requirement: Information transfer rules, procedures and agreements in place for all types of transfer.

Implementation:

• TLS 1.3 for all API communications, HTTPS everywhere
• HMAC-SHA256 authentication for APIs with nonce-based replay protection
• No email transfer of secrets; Signal for sensitive communications
• API terms of service and data processing agreements where applicable
• Phishing awareness training for electronic messaging

Evidence: TLS configurations, API authentication code, terms of service, supplier agreements

Docs gateway application (planned end state): Transfers between the docs gateway handler and upstream sandbox services (provii-verifier, provii-issuer) use Cloudflare Service Bindings rather than public fetch() calls, removing per-request DNS and TLS handshake surfaces. __Host-docs_session cookies are issued with the __Host- prefix (secure, HttpOnly, SameSite=Strict, path=/, no Domain attribute) and signed with DOCS_SESSION_HMAC_KEY.

Task: (Service Bindings wiring for docs gateway -> provii-verifier/provii-issuer) is PENDING. Until that task ships, upstream calls run over public fetch() and the Service Bindings element of this control is not yet at the planned end state.

Requirement: Access control policy established, documented and reviewed based on business and information security requirements.

Implementation:

• Access Control Policy defined
• Principle of least privilege
• Role-based access where applicable
• MFA required for critical systems
• Regular access reviews

Evidence: Access control policy, access audit logs

Docs gateway application: Access to gateway endpoints under /api/* is gated on a valid __Host-docs_session bearer with a kid prefix for HMAC key rotation. Bearer lookup is kid-keyed and single-shot, never try-both-keys. A revocation KV list is consulted on every /api/* handler with a 30-second cf.cacheTtl. Origin header pinning rejects requests whose Origin does not match the allowed docs origin list.

Requirement: Full lifecycle of identities managed.

Implementation:

• GitHub accounts and Cloudflare accounts serve as identity providers
• No shared accounts permitted
• Identity lifecycle managed through onboarding/offboarding checklists
• Unique identifiers for all personnel

Evidence: Account provisioning records, onboarding/offboarding checklists

Requirement: Allocation and management of authentication information controlled through a management process.

Implementation:

• GitHub: Personal Access Tokens, MFA required
• Cloudflare: API tokens with minimal scopes, MFA required
• Password managers required (1Password or Bitwarden)
• No shared accounts, no password reuse
• Credential rotation on personnel departure
• Secrets never in source code or logs

Evidence: MFA enforcement logs, secret rotation records, offboarding checklists

Requirement: Access rights provisioned, reviewed, modified and removed in accordance with policy.

Implementation:

• GitHub admin: Limited to the ISMS Owner (sole operator)
• Cloudflare admin: Limited to the ISMS Owner (sole operator)
• Production KV access: Only via Workers (no direct access)
• Quarterly access reviews conducted
• Immediate revocation on termination, adjustment on role change
• Offboarding checklist enforced and verified in access reviews

Evidence: Access control lists, privilege audit logs, quarterly access review reports, offboarding records

Requirement: Processes and procedures defined to manage information security risks associated with suppliers.

Implementation:

• Supplier Management Procedure defined
• Critical suppliers: Cloudflare, GitHub
• Requirements documented in risk register
• Service Level Agreements reviewed
• Vendor security assessments

Evidence: Supplier management procedure, vendor assessments

Docs gateway application: The docs gateway introduces Cloudflare Bot Fight Mode, Cloudflare Super Bot Fight Mode, Cloudflare Rate Limiting API, and Cloudflare R2 as supplier-provided capabilities. Each is processed under the existing Cloudflare master supplier relationship. Scalar (OpenAPI documentation renderer) is tracked as a supply chain dependency and is subject to Dependabot grouped npm updates on the provii-docs repository.

Requirement: Relevant information security requirements established and agreed with each supplier.

Implementation:

• Cloudflare: Enterprise reliability, target 99.9% uptime, DDoS protection
• GitHub: Enterprise Cloud, security features, support SLA
• Terms of Service reviewed for security provisions
• Data processing agreements where applicable

Evidence: Service agreements, Terms of Service review records

Requirement: Processes and procedures defined to manage information security risks in the ICT product and services supply chain.

Implementation:

• SLSA Level 3 for our artifacts
• Dependency security scanning (cargo audit, npm audit)
• Hermetic builds prevent supply chain tampering
• Artifact signing and provenance
• Monitor supplier security advisories

Evidence: CI/CD security scans, SLSA provenance, signed artifacts

Docs gateway application: The docs gateway takes a direct supply chain dependency on Scalar (browser OpenAPI renderer) and the provii-crypto-commons TS bindings used for attestation canonical-message computation. Both are pinned and subject to grouped Dependabot updates. Sandbox paths are gated behind a Cargo feature flag sandbox_only_register_test_issuer_client plus a CARGO_CFG_PROVII_ENV=sandbox build assertion; a CI bundle-grep job confirms prod wasm does not carry docs-sbx-* or mwallet-sbx-* strings, with a high-entropy base64 scan as defence in depth against Ed25519 seed leaks.

Requirement: Organisation regularly monitors, reviews, evaluates and manages change in supplier information security practices and service delivery.

Implementation:

• Cloudflare status page monitoring
• GitHub status page monitoring
• Annual supplier review against security requirements
• Service change notifications tracked

Evidence: Supplier review records, status monitoring configuration

Requirement: Processes for acquisition, use, management and exit from cloud services established in accordance with security requirements.

Implementation:

• Cloudflare Workers is the primary cloud platform
• Security responsibilities understood (shared responsibility model)
• SLA reviewed annually
• Cloud-native architecture designed for portability where feasible
• Wrangler CLI for all deployment and configuration

Evidence: Cloud architecture documentation, SLA review records, wrangler.toml configurations

Docs gateway application (planned end state): New Cloudflare-provided capabilities are in use for the docs gateway: Bot Fight Mode (bot challenge), Super Bot Fight Mode (Pro+ zone feature), Rate Limiting API binding, Secrets Store bindings (DOCS_SESSION_HMAC_KEY, DOCS_ATTESTATION_ED25519_SEED, SANDBOX_ISSUER_API_KEY, DOCS_CSRF_HMAC_KEY), and the new DOCS_SESSIONS KV namespace. Service Bindings replace public fetch() for every upstream call from the gateway to sandbox provii-verifier and provii-issuer.

Task: (Service Bindings wiring for docs gateway -> provii-verifier/provii-issuer) is PENDING. The Service Bindings replacement of public fetch() is not yet in place; the other listed Cloudflare bindings are configured.

Requirement: Management responsibilities and procedures established for effective incident management.

Implementation:

• Incident Response Policy documented
• Clear roles: Security Lead (lead), escalation to ISMS Owner
• Severity levels defined (P0-P3)
• Contact: security@maelstrom.au (24/7 monitoring)
• GitHub Security Advisories for code vulnerabilities
• Responsible disclosure encouraged
• All team members trained to report, no penalties for good-faith reporting

Evidence: Incident response policy, incident tickets, post-mortems, training records

Requirement: Information security events assessed and it is decided if they are to be categorised as information security incidents.

Implementation:

• Security Lead performs triage
• Severity assessment (P0-P3)
• Documented in incident tickets
• Escalation criteria clear

Evidence: Incident response procedures, triage records

Requirement: Information security incidents responded to in accordance with documented procedures.

Implementation:

• Documented response procedures by scenario
• Containment, eradication, recovery, lessons learned
• Post-incident reviews mandatory
• Continuous improvement

Evidence: Incident response procedures, post-incident reports

Requirement: Knowledge gained from information security incidents used to strengthen controls.

Implementation:

• Post-incident reviews mandatory
• Action items tracked
• Risk register updated
• Procedures improved
• Lessons shared (blameless culture)

Evidence: Post-incident reports, action item tracking

Requirement: Procedures for identification, collection, acquisition and preservation of evidence defined and applied.

Implementation:

• Audit logging in Cloudflare KV (90-day retention; critical security event logs are retained for up to 365 days)
• GitHub audit logs retained
• Cloudflare Workers Logs (shipped to Grafana Loki) for request data
• Evidence Collection Checklist documented
• Chain of custody procedures for security events

Evidence: Audit log configurations, evidence collection checklist

Requirement: Organisation plans how to maintain information security at an appropriate level during disruption.

Implementation:

• Business Continuity Plan documented
• RTOs and RPOs defined
• Disaster scenarios documented
• Recovery procedures tested

Evidence: Business continuity plan, test results

Requirement: ICT readiness planned, implemented, maintained and tested based on business continuity objectives.

Implementation:

• Cloudflare automatic failover across 300+ PoPs
• Geographic distribution provides resilience
• Backup-worker provides automated encrypted backups (RPO under 1 hour, RTO under 4 hours)
• Gap. First full BCP tabletop exercise not yet conducted

Planned: Tabletop exercise H1 2026, annual testing thereafter

Evidence: BCP document, infrastructure architecture, provii-backup evidence

Docs gateway application: The gateway supports per-widget feature flags read from docs-features:<widget>:enabled with 60-second cache, plus a global kill switch at docs-features:gateway:disabled. Either mechanism allows rapid containment of a bad release without a full redeploy. A documented rollback runbook covers wrangler kv:key list --remote --prefix docs-sbx- sweeps of both SANDBOX_DOCS_ISSUERS and SANDBOX_MOBILE_ISSUERS and is exercised quarterly.

Requirement: Legal, statutory, regulatory and contractual requirements identified, documented and kept up to date.

Implementation:

• Australian Privacy Act 1988 compliance
• Minimal data collection simplifies compliance
• Legal requirements reviewed annually
• External legal counsel consulted when needed

Evidence: Compliance register, legal review records

Requirement: Compliance with legal, statutory, regulatory and contractual requirements related to intellectual property rights.

Implementation:

• Provisional patent filed with IP Australia (AU 2026901546, filed 2026-02-26)
• Trade mark application filed for PROVII WALLET (AU Classes 9 and 42, filed 2026-02-22)
• Domain portfolio maintained (provii.app,.au,.com.au,.com)
• Open source licences documented per repository (AGPL-3.0-only, Apache-2.0, MIT, proprietary)
• Dependency licences reviewed for compatibility
• Copyright notices in all files
• IP assets tracked in Asset Register
• Key deadlines monitored (PCT filing by 2027-02-26, domain renewals, trade mark maintenance)

Evidence: IP Register (provii-admin), LICENSE files, dependency audits, Asset Register

Requirement: Records protected from loss, destruction, falsification, unauthorised access and release.

Implementation:

• Source code in Git (immutable history)
• Audit logs in Cloudflare KV (append-only pattern)
• Backup procedures for critical data (provii-backup: AES-256-GCM encrypted)
• Access controls on all record systems

Evidence: Version control, audit log architecture, provii-backup

Docs gateway application: Audit events produced by the docs gateway (session init, credential mint, challenge create, attestation sign, rate-limit trips, revocation hits) are emitted as structured JSON log lines with an event_type label and HMAC’d identifiers, then shipped via Cloudflare Workers Logs to Grafana Loki under the docs labelset. A log_sanitizer module ported from provii-verifier enforces HMAC-SHA256 redaction before any console.log emit. A CI regex guard fails the build if any log emit mentions a secret name. Retention is 90 days (critical security event logs are retained for up to 365 days), consistent with the existing audit log posture.

Requirement: Privacy and protection of personal information ensured as required by applicable legislation.

Implementation:

• Minimal personal information processing. during issuance, DOB is transmitted once to the issuer API for Pedersen commitment computation, processed ephemerally, and immediately discarded (never stored, logged, or retained). During verification, no personal information is transmitted.
• IP addresses in logs (90-day retention; critical security event logs are retained for up to 365 days)
• Australian Privacy Act compliance
• No GDPR obligations (no EU data processing)

Evidence: Architecture documentation, data flow diagrams, privacy assessment

Docs gateway application: The docs gateway never accepts raw dates of birth from onboarding developers. Fixture input is fixture-ID-only; real-DOB payloads are rejected by schema validation and logged as suspicious. The gateway processes two developer-facing PII elements under legitimate interest: a pseudonymous session_id (bound to __Host-docs_session) and IP-derived rate-limiting keys. Both are covered by a DPIA at security/dpia-docs-sandbox.md and a separate Children’s Code Standard 2 DPIA at compliance/standards/childrens-code/dpia-children.md.

Requirement: Organisation’s approach to managing information security independently reviewed at planned intervals.

Implementation:

• Internal audits conducted (self-assessment)
• Gap. External audit not yet performed

Planned: External ISO 27001 certification audit when commercially justified

Evidence: Internal audit reports, certification planning

Requirement: Compliance with policies, rules and standards regularly reviewed.

Implementation:

• Annual policy review
• Quarterly risk register review
• Internal audit programme
• Management review process

Evidence: Review schedules, audit reports, management review minutes

Requirement: Operating procedures for information processing facilities documented and made available to personnel who need them.

Implementation:

• CI/CD security scans (non-disruptive)
• Cloudflare handles OS-level security (serverless)
• Operational runbooks published in ISMS documentation
• Developer workstation security documented in acceptable use policy

Evidence: CI/CD scan logs, operational procedures, serverless architecture documentation

Docs gateway application: Docs gateway operations are captured in dedicated runbooks covering bearer kid rotation (90-day cadence), SANDBOX_DOCS_ISSUERS and SANDBOX_MOBILE_ISSUERS sweep-delete procedures, feature-flag containment, quarterly rotation of the shared sandbox issuer identity, and JWKS rotation for the shared sandbox issuer. Procedures are cross-linked from operations/incident-response-playbook.md.

Requirement: Background verification checks on candidates for employment carried out.

Implementation:

• Background checks conducted for new hires
• Professional references checked
• LinkedIn/GitHub profiles reviewed
• Criminal background checks where legally permitted

Evidence: Hiring records, background check results (confidential)

Requirement: Contractual agreements state responsibilities for information security.

Implementation:

• Employment contracts include security responsibilities
• Confidentiality clauses
• Acknowledgment of policies required
• Contractor agreements include security terms

Evidence: Employment contracts, contractor agreements

Requirement: Personnel and contractors receive appropriate information security awareness education and training.

Implementation:

• Security Awareness Training Program
• Onboarding security training
• Annual refresher training
• Ad-hoc training for emerging threats
• Phishing awareness

Evidence: Training records, attendance logs, test results

Requirement: Formal disciplinary process for personnel who have committed an information security breach.

Implementation:

• Defined in employment agreements
• Progressive discipline (verbal warning, written warning, termination)
• Documented in Information Security Policy
• Applied consistently

Evidence: Disciplinary procedures, incident records (confidential)

Requirement: Information security responsibilities that remain valid after termination or change defined, enforced and communicated.

Implementation:

• Confidentiality obligations survive termination
• Documented in employment contracts
• Return of assets required
• Continued restrictions on disclosure

Evidence: Employment contracts, offboarding procedures

Requirement: Confidentiality or non-disclosure agreements reflecting the organisation’s needs for protection of information identified and regularly reviewed.

Implementation:

• NDAs with all team members
• NDAs with contractors and consultants
• NDAs with business partners (as appropriate)
• Reviewed by legal counsel

Evidence: Signed NDA agreements

Requirement: Security measures implemented when personnel work remotely.

Implementation:

• Fully remote team - this is our standard operating model
• VPN not required (zero-trust architecture)
• MFA required for all access
• Device security requirements in Acceptable Use Policy
• Home network security guidance provided

Evidence: Remote work policy, acceptable use policy, security training

Requirement: Organisation provides a mechanism for personnel to report observed or suspected information security events in a timely manner.

Implementation:

• security@maelstrom.au
• Multiple reporting channels (email, Signal, direct contact)
• No-blame culture
• Timely response targeted

Evidence: Incident reporting procedures, incident tickets

Requirement: Security perimeters defined and used to protect areas containing information and information processing facilities.

Justification: No company offices (fully remote). No data centres (serverless on Cloudflare). Cloudflare manages data centre physical security.

Compensating Controls: Cloud provider physical security certifications, Acceptable Use Policy for remote work, device security requirements

Requirement: Secure areas protected by appropriate entry controls.

Justification: No company facilities. Fully remote team with no data centres or offices.

Compensating Controls: Cloudflare/GitHub data centre entry controls (provider responsibility)

Requirement: Physical security for offices, rooms and facilities designed and implemented.

Implementation:

• Team members responsible for home office security
• Guidance provided in acceptable use policy
• Limitation. Cannot enforce physical controls in home offices

Compensating Controls: Full disk encryption required, screen locks required (5-minute timeout), no shared workspaces, device security training

Evidence: Acceptable use policy, security training

Requirement: Premises continuously monitored for unauthorised physical access.

Justification: No company premises. Cloudflare/GitHub handle monitoring of their facilities.

Compensating Controls: Cloud provider monitoring, logical access controls

Requirement: Protection against physical and environmental threats designed and implemented.

Implementation:

• Cloud infrastructure. Cloudflare/GitHub responsibility (covered in SLAs)
• Endpoints. Device security requirements in acceptable use policy
• Environmental. Remote work means distributed risk (no single point of failure)

Evidence: SLA agreements, acceptable use policy

Requirement: Security measures for working in secure areas designed and implemented.

Implementation:

• Team members work from home (private, secure)
• Public WiFi discouraged for sensitive work
• VPN available if needed
• Limitation. Cannot fully control home environment

Compensating Controls: Full disk encryption, screen locks, VPN option

Evidence: Acceptable use policy, security training

Requirement: Clear desk and clear screen rules defined and enforced.

Implementation:

• Remote work (limited physical document risk)
• Screen locks required (5-minute timeout)
• Auto-lock on laptop close
• No printing of sensitive information
• Privacy screens encouraged for public spaces

Evidence: Acceptable use policy, security training

Requirement: Equipment sited and protected to reduce risks from environmental threats and unauthorised access.

Implementation:

• Laptops: Individual responsibility per acceptable use policy
• Production infrastructure: Cloudflare data centres (enterprise-grade protection)
• No on-premise servers

Evidence: Acceptable use policy, cloud architecture

Requirement: Off-site assets protected.

Implementation:

• Full disk encryption mandatory
• Strong passwords/biometric unlock
• Physical security awareness training
• Lost device reporting procedures
• Remote wipe capability

Evidence: Acceptable use policy, device management

Requirement: Storage media managed through their lifecycle of acquisition, use, transportation and disposal.

Implementation:

• Full disk encryption on all endpoints (FileVault, BitLocker)
• Cryptographic erasure on repurpose (delete encryption keys)
• No removable media for sensitive data
• Cloud storage encrypted at rest (Cloudflare KV, R2)

Evidence: Acceptable use policy, data retention policy

Requirement: Information processing facilities protected from power failures and other disruptions caused by failures in supporting utilities.

Justification: Production runs on Cloudflare (UPS, generators, redundant power are provider responsibility). Development on individual laptops with batteries. Cloud-native architecture is resilient to local power outages.

Compensating Controls: Cloudflare SLA, distributed architecture

Requirement: Cables carrying power and data or supporting information services protected from interception, interference or damage.

Justification: Cloudflare/GitHub manage infrastructure cabling. Home offices out of scope.

Compensating Controls: Encryption in transit (TLS 1.3), cloud provider controls

Requirement: Equipment maintained correctly to ensure availability and integrity.

Implementation:

• Production infrastructure. Cloudflare maintains (serverless model)
• Development workstations. Individual responsibility
• OS updates required
• Security patches required
• Hardware maintenance individual responsibility

Evidence: Acceptable use policy, OS update requirements

Requirement: Items of equipment containing storage media verified to ensure sensitive data has been removed or securely overwritten prior to disposal or re-use.

Implementation:

• Full disk encryption (data inaccessible without key)
• Cryptographic erasure on repurpose (delete encryption keys)
• Physical destruction for highly sensitive devices
• Documented in Data Retention and Disposal Policy

Evidence: Data retention policy, disposal procedures

Requirement: Information stored on, processed by or accessible via user endpoint devices protected.

Implementation:

• Full disk encryption required (FileVault, BitLocker)
• OS-level security features (Gatekeeper, macOS XProtect)
• Automatic security updates required
• Password managers required
• MFA required for cloud access

Evidence: Acceptable use policy, security training

Requirement: Allocation and use of privileged access rights restricted and managed.

Implementation:

• Admin access limited to the ISMS Owner (sole operator) for GitHub and Cloudflare
• No shared administrative accounts
• API tokens scoped to minimal permissions
• Signing keys isolated in Cloudflare KV (AES-256-GCM envelope encryption)
• Audit logging for all privileged actions

Evidence: Access control policy, audit logs, privilege inventory

Docs gateway application: Docs gateway privileged material (DOCS_SESSION_HMAC_KEY, DOCS_ATTESTATION_ED25519_SEED, SANDBOX_ISSUER_API_KEY, DOCS_CSRF_HMAC_KEY) is bound via Secrets Store. The Ed25519 seed is wrapped in an AttestationSigner class that holds the seed in closure and exposes only sign(message: Uint8Array); it throws on toString() and toJSON() so the seed cannot be materialised as a JS string.

Requirement: Access to information and other associated assets restricted in accordance with access control policy.

Implementation:

• GitHub: Repository permissions, branch protection
• Cloudflare: Role-based access, API token scoping
• KV: Access only via Workers (no direct access)
• Principle of least privilege

Evidence: Access control lists, permission audits

Docs gateway application: The docs handler receives a narrowed DocsEnv subtype rather than the full playground env. DEMO_TOKEN_SECRET and playground-scoped KVs are not present in the docs bindings, preventing cross-surface state reads even under a handler-logic bug. Module-level caches from the legacy playground handler have been moved into per-handler scope so isolate-level cache poisoning across surfaces is not possible.

Requirement: Read and write access to source code, development tools and software libraries managed.

Implementation:

• Public source code. Open source (transparent access)
• Code review required for all changes
• Branch protection enforces review before merge
• Self-review via pull request is the compensating control; no two-person review is feasible for a sole operator

Evidence: GitHub repository settings, contribution guidelines

Requirement: Secure authentication technologies and procedures established based on information access restrictions.

Implementation:

• MFA required for all platforms (GitHub, Cloudflare, email)
• Strong password requirements enforced via password managers
• API authentication: HMAC-SHA256 with nonce-based replay protection
• YubiKey HMAC-SHA1 for officer authentication
• No hard-coded credentials

Evidence: MFA enforcement logs, authentication code, password manager usage

Docs gateway application: Developers onboarding through the gateway authenticate via an Cloudflare managed challenge at POST /api/session/init. On success, the gateway issues a __Host-docs_session cookie HMAC-signed with DOCS_SESSION_HMAC_KEY, carrying a kid prefix, with a 15-minute sliding TTL and 4-hour hard cap. Cookie-value comparison uses crypto.subtle.timingSafeEqual. Timing-attack hardening pads the /session/init response to a fixed 250ms wall-clock deadline with Cloudflare Bot Fight Mode providing edge-level bot detection.

Requirement: Use of resources monitored and adjusted, and projections made of future capacity requirements.

Implementation:

• Cloudflare Workers: Automatic scaling (no capacity planning needed)
• Durable Objects: Automatic distribution
• KV: Effectively unlimited capacity
• Monitoring: Cloudflare Workers Logs (shipped to Grafana Loki)

Evidence: Cloudflare automatic scaling, Grafana Loki dashboards

Requirement: Protection against malware implemented and supported by appropriate user awareness.

Implementation:

• Production. Serverless (no persistent malware possible)
• Development workstations. OS-level protection (macOS XProtect, Windows Defender), browser security features, security awareness training
• Only trusted sources for software

Evidence: Acceptable use policy, security training

Requirement: Information about technical vulnerabilities obtained, exposure evaluated, and appropriate measures taken.

Implementation:

• GitHub Security Alerts (dependency vulnerabilities)
• cargo audit, npm audit in CI/CD
• Rust Security Advisory Database monitoring
• Rapid patch deployment via CI/CD
• Vulnerability disclosure programme

Evidence: CI/CD security scan logs, patch deployment records

Requirement: Configurations, including security configurations, of hardware, software, services and networks established, documented, implemented, monitored and reviewed.

Implementation:

• Infrastructure as code (wrangler.toml in Git for all Workers)
• Configuration changes exclusively via pull request process
• No manual production configuration permitted
• Environment-specific configurations tracked in version control
• CI/CD validates configuration before deployment

Evidence: wrangler.toml files, Git history, CI/CD configuration validation logs

Docs gateway application: Route assignment switches provii-docs/wrangler.toml from custom_domain = true to a glob pattern docs.provii.app/*, with docs.provii.app/api/* bound to the provii-demos/demo-web-provii-agegate Worker. Longest-prefix wins; /api/* routes to the docs gateway, everything else routes to the static docs site. UAT mirrors exist on uat-docs.provii.app. Tom confirms zero zone-level Cache Rules match docs.provii.app/* with Cache Level greater than Bypass (CSP nonce depends on per-request rendering).

Requirement: Information stored in information systems, devices or any other storage media deleted when no longer required.

Implementation:

• Data Retention and Disposal Policy defined
• Audit logs (including IP addresses): 90-day retention; critical security event logs are retained for up to 365 days
• Ephemeral state (challenges, nonces): Auto-expire
• No PII to delete (zero knowledge architecture)

Evidence: Data retention policy, automated deletion procedures

Requirement: Data masking used in accordance with the organisation’s topic-specific policy on access control and business requirements.

Justification: Minimal PII processing (DOB processed ephemerally during issuance, never persisted). Zero knowledge architecture eliminates the need for data masking. IP addresses in logs are the only potentially sensitive data and are subject to 90-day retention; critical security event logs are retained for up to 365 days.

Compensating Controls: Zero knowledge architecture is designed to minimise PII collection

Requirement: Data leakage prevention measures applied to systems, networks and any other devices that process, store or transmit sensitive information.

Implementation:

• Secrets never in source code (secret scanning in CI)
• No PII in logs
• TLS 1.3 for all communications
• Cloudflare KV for secrets (not Git)
• Code scanning detects secret leakage
• Zeroisation of secrets in memory (Rust)

Evidence: Secret scanning, code review, TLS configuration

Docs gateway application: An ESLint rule at provii-demos/demo-web-provii-agegate/.eslintrc bans raw console.* in src/docs/**; all logging routes through a log_sanitizer TS module ported from provii-verifier that HMAC-SHA256-redacts secret material before any console.log emit shipped via Workers Logs to Grafana Loki. The release wasm for prod-profile provii-verifier and provii-issuer is scanned for docs-sbx-*, mwallet-sbx-*, register-test-issuer-client strings, and base64 blobs of length 43-44 (Ed25519 seed shape) to catch accidental leakage.

Requirement: Backup copies of information, software and systems maintained and regularly tested in accordance with the agreed topic-specific policy on backup.

Implementation:

• Source code. Git (multiple clones, GitHub backup)
• Infrastructure as code. In Git (wrangler.toml, CI/CD workflows)
• KV data. Automated provii-backup
• Hourly full backups (all KV keys)
• Daily full snapshots (2am UTC)
• Weekly complete backups (Sunday 3am UTC)
• Coverage: 30 KV namespaces, 9 Durable Objects, 2 R2 buckets
• Encryption: AES-256-GCM
• Compression: 70-80% size reduction
• RPO: under 1 hour, RTO: under 4 hours
• Storage: Cloudflare R2 (geo-distributed)

Evidence: provii-backup implementation, Git backups, Cloudflare replication

Requirement: Information processing facilities implemented with sufficient redundancy to meet availability requirements.

Implementation:

• Cloudflare: 300+ PoPs globally
• Automatic failover
• Durable Objects replication
• Geographic distribution
• 99.9%+ availability target

Evidence: Cloudflare architecture, availability monitoring

Requirement: Logs that record activities, exceptions, faults and other relevant events produced, stored, protected and analysed.

Implementation:

• Cloudflare Workers Logs shipped to Grafana Loki (request logs, structured JSON with event_type label and HMAC’d identifiers)
• Audit logs in KV (security events, append-only pattern)
• GitHub audit logs
• Structured logging in Workers
• Authentication attempts logged
• Access controls on log namespaces, no PII in logs

Evidence: Log configurations, audit log architecture, append-only implementation

Requirement: Networks, systems and applications monitored for anomalous behaviour and appropriate actions taken.

Implementation:

• GitHub audit logs (admin actions) reviewed
• Cloudflare audit logs (admin actions) reviewed
• KV access logging
• Cloudflare Workers Logs (shipped to Grafana Loki) for traffic anomalies
• Gap. Formalised regular review cadence not yet fully established

Planned: Formalise weekly monitoring review process (H1 2026)

Evidence: Audit log configurations, monitoring dashboards

Docs gateway application: Docs gateway traffic is emitted as structured JSON log lines via Workers Logs and shipped to Grafana Loki under the docs labelset, with handler-scoped labels for correlation. Cloudflare Bot Fight Mode challenge volume is alarmed at 500k/day via Cloudflare Notifications. A WAF custom rule on /api/* runs in “Log only” mode for a fortnight with weekly review before escalation to Managed Challenge. OPTIONS preflights and verified search-engine bot traffic are skipped. Rate-limit trips, revocation hits, and attestation-session mismatches emit dedicated event types for correlation against abuse investigations.

Requirement: Clocks of information processing systems synchronised to approved time sources.

Implementation:

• Cloudflare Workers: NTP synchronisation automatic
• GitHub timestamps: System-managed
• Developer workstations: OS-level NTP

Evidence: System configurations, timestamp accuracy

Requirement: Use of utility programs that might be capable of overriding system and application controls tightly controlled and restricted.

Implementation:

• Wrangler CLI is the sole tool for production deployment and KV access
• Access restricted to authorised personnel only
• All wrangler actions logged via Cloudflare audit trail
• No direct database or KV access outside of Workers runtime

Evidence: Cloudflare audit logs, access control policy, deployment procedures

Requirement: Procedures and measures implemented to securely manage software installation on operational systems.

Implementation:

• Production. Immutable (serverless Workers, deployed only via CI/CD)
• Development. Individual workstations, controlled via acceptable use guidelines
• Only trusted sources for software
• Hermetic builds prevent unauthorised software in artefacts

Evidence: Deployment procedures, acceptable use policy

Requirement: Networks and network devices secured, managed and controlled to protect information in systems and applications.

Implementation:

• Cloudflare provides network security (DDoS, WAF, TLS termination)
• No traditional network to configure (serverless)
• TLS 1.3 for all external communications
• Cloudflare edge security automatic

Evidence: Cloudflare configuration, TLS enforcement

Docs gateway application: CORS for the docs gateway is isolated in provii-demos/demo-web-provii-agegate/src/docs/cors.ts with its own ALLOWED_DOCS_ORIGINS constant and getAllowedDocsOrigin helper, fully duplicated from playground CORS rather than sharing mutable state. Origin header pinning rejects cross-surface requests. CORS_ORIGINS in provii-verifier and provii-issuer sandbox envs includes docs.provii.app, uat-docs.provii.app, and preview.docs-sandbox.provii.app; credentials are not permitted on docs preflights. Origin+bearer enforcement routes Origin-less requests to a stricter public tier to prevent curl-spoofed docs-tier budget exhaustion.

Requirement: Security mechanisms, service levels and service requirements of network services identified, implemented and monitored.

Implementation:

• Cloudflare provides the network security layer (DDoS protection, TLS termination, WAF)
• Cloudflare Enterprise SLA includes security provisions
• GitHub Enterprise Cloud includes security features
• Security requirements documented in service agreements

Evidence: Cloudflare security features, monitoring dashboards, SLA documents

Docs gateway application (planned end state): Upstream fabric calls from the docs gateway to provii-verifier and provii-issuer use Cloudflare Service Bindings (VERIFIER_API_SANDBOX, ISSUER_API_SANDBOX) rather than public HTTPS fetch(). Internal-fabric calls incur no public DNS resolution, no per-request TLS handshake, and no DNS-poisoning surface. Rate limiting for polling endpoints uses the Cloudflare Rate Limiting API binding, with creation endpoints gated by KV counters on a 1-minute window keyed on bearer HMAC; fail-closed when tier-limits read fails.

Task: (Service Bindings wiring for docs gateway -> provii-verifier/provii-issuer) is PENDING. Until that task ships, upstream fabric calls run over public fetch() and the public-DNS / TLS-handshake surface reduction is not yet realised.

Requirement: Groups of information services, users and information systems segregated in networks.

Implementation:

• Production. Cloudflare Workers (isolated V8 isolate execution)
• Development. Local workstations (wrangler dev —local)
• Secrets. KV namespaces per environment
• No shared development/production resources

Evidence: Environment separation, wrangler.toml configurations

Docs gateway application: The docs gateway and playground handler share a single Worker runtime (provii-demos/demo-web-provii-agegate) but run in disjoint network boundaries enforced by an early-dispatch host-and-path guard in src/index.ts fetch(). Subdomain “docs” delegates to src/docs/handler.ts with DocsEnv; other subdomains stay on the legacy switch; cross-surface mismatches 403. Vitest suites assert cross-surface KV access is blocked, path-fuzz variants (/Api/, /api/..\session, /api/%2e%2e/session) all route to the docs handler without reaching playground bindings, and docs cache reads do not mutate playground cache.

Requirement: Access to external websites managed to reduce exposure to malicious content.

Implementation:

• Production. No outbound web access (serverless Workers fetch only from specific APIs)
• Development. Individual responsibility, browser security features, training

Evidence: Worker code review, acceptable use policy

Docs gateway application: Cloudflare Super Bot Fight Mode is enabled on the provii.app zone (Pro+ tier). A WAF custom rule filters /api/* traffic on docs.provii.app in “Log only” first fortnight mode before escalation to Managed Challenge. Edge-level bot mitigation is applied before handler code executes, reducing exposure of the gateway to automated credential harvesting and scraping.

Requirement: Rules for the effective use of cryptography, including cryptographic key management, defined and implemented.

Implementation:

• Cryptography Policy defined
• Groth16 ZKP (BLS12-381 curve), Pedersen commitments (JubJub curve)
• RedJubjub signatures for attestations
• BLAKE2, SHA-256 hashing
• TLS 1.3 for all communications
• AES-256-GCM envelope encryption for signing keys in KV
• Key generation ceremonies documented, rotation procedures defined

Evidence: Cryptography policy, code implementation, JWKS, key management procedures

Docs gateway application: The docs gateway introduces two new keys covered by the Cryptography Policy: DOCS_SESSION_HMAC_KEY (HMAC-SHA-256, signs __Host-docs_session cookies, 90-day rotation via kid prefix, old and new keys retained for the 4-hour session hard-cap window) and DOCS_ATTESTATION_ED25519_SEED (Ed25519 seed for sandbox attestation signing, distinct from production seeds, rotated quarterly). Attestation canonical messages now include session_id and client_id fields hashed via Blake2s; golden-vector fixtures are committed across provii-verifier, provii-issuer, and the TS gateway with a CI equality check to prevent drift.

Requirement: Rules for the secure development of software and systems established and applied.

Implementation:

• Security testing in CI/CD (CodeQL, cargo audit, npm audit)
• Mandatory code review for all changes
• Dependency scanning on every build
• Threat modelling for new features
• Secure SDLC documented
• Security requirements in design phase, security testing before deployment

Evidence: CI/CD workflows, code review requirements, development procedures

Docs gateway application (planned end state): Docs gateway development follows the docs-sandbox-gateway Design Spec (Appendix A of the ISMS) and is tracked as a new preventive control UC-186 in the unified control matrix, mapped to A.8.25 and A.8.31. CODEOWNERS requires dual review on src/docs/** and on shared paths (jsonResponse, getAllowedOrigin, BASE_SECURITY_HEADERS). Threat modelling artefacts include the security-review findings and the adversarial-review AR-S/AR-C items referenced in the tracker.

Task: UC-186 is itself recorded as ”🔄 Planned” in the Unified Control Matrix (see “Current Status” line). Implementation tracked under tasks 0.46 (Cargo feature flag. DONE), 0.47 (build.rs + CARGO_CFG_PROVII_ENV assertion. PENDING) and 0.49 (production middleware rejection of docs-sbx-* / mwallet-sbx-* prefixes. PENDING). Status downgraded to align with the matrix.

Requirement: Information security requirements identified, specified and approved when developing or acquiring applications.

Implementation:

• Security requirements documented for each service
• Threat models created before implementation of new features
• HMAC-SHA256 API authentication with nonce-based replay protection as standard
• Zero knowledge proof architecture requirements (Groth16/BLS12-381)
• PKCE for verifier flows

Evidence: Threat models, security requirements documents, API specifications

Docs gateway application: Security requirements for the docs gateway include: Cloudflare managed challenge at the edge, __Host-docs_session cookie, bearer kid rotation, per-bearer lifetime credential mint caps (3 verifier + 3 issuer), hard poll-count ceiling (30 polls per challenge, 500 polls/day per bearer), client_id + session_id binding in attestation canonical messages, and a fixture-ID-only input schema on /v1/register-test-issuer-client. Feature-flag gating (docs-features:<widget>:enabled) and a global kill switch permit rapid rollback without redeploy.

Requirement: Principles for engineering secure systems established, documented, maintained and applied to any information system development activity.

Implementation:

• Zero knowledge by design (avoid PII entirely)
• Defence in depth
• Least privilege
• Fail-safe defaults
• Edge-based security (Cloudflare Workers)
• Architecture documentation maintained

Evidence: Architecture docs, design documents, threat models

Docs gateway application (planned end state): The docs gateway applies defence in depth across four layers: Cloudflare edge (Bot Fight Mode + WAF managed challenges), Worker entry (host-and-path guard, narrowed DocsEnv, Service Bindings), handler logic (bearer kid rotation, hard poll ceilings, origin+bearer enforcement, Ed25519 seed wrapped in AttestationSigner closure), and upstream APIs (Cargo feature flag plus CARGO_CFG_PROVII_ENV build assertion, middleware-level rejection of docs-sbx-* and mwallet-sbx-* prefixes in prod). Fail-safe defaults: fail-closed when rate-limit reads fail, fail-closed when Cloudflare Bot Fight Mode challenge is unreachable.

Task: (Service Bindings) and (build.rs + CARGO_CFG_PROVII_ENV=sandbox build assertion) are PENDING. The defence-in-depth chain is complete only at the edge and Worker-entry layers; the upstream-API compile-time guard and the Service Bindings element of Worker entry are not yet shipped.

Requirement: Secure coding principles applied to software development.

Implementation:

• Rust’s memory safety for backend services (no unsafe code in production)
• Clippy linting enforced in CI
• CodeQL scanning for TypeScript repositories
• Input validation via Zod (TypeScript) at all boundaries
• No use of any type in TypeScript (strict mode)
• Secret scanning prevents credential leakage

Evidence: CI/CD linting results, CodeQL scan reports, code review records

Docs gateway application: Input validation in the docs gateway uses a dedicated DocsSessionSchema (Zod) and KV key-prefix schemas (docs-session:*, docs-cred-v:*, docs-cred-i:*, docs-chal:*, ratelimit:docs:*). Prod-side rejection of docs-sbx-* and mwallet-sbx-* client prefixes is implemented as middleware in provii-management and provii-verifier, covering body, path params, query params, and any headers read during auth (X-Client-Id, X-API-Key, Authorisation). Secrets comparison uses subtle::ConstantTimeEq::ct_eq() (Rust) and crypto.subtle.timingSafeEqual (Workers).

Requirement: Security testing processes defined and implemented in the development life cycle.

Implementation:

• Unit tests (including security-focused tests)
• Integration tests (E2E scenarios)
• Property-based testing (proptest for Rust, fast-check for TypeScript)
• Fuzzing (cargo-fuzz)
• Static analysis (CodeQL)
• All CI/CD tests must pass before deployment
• Code review approval required, security scan approval required

Evidence: Test suites, CI/CD test results, approval gates, deployment logs

Docs gateway application (planned end state): Miniflare plus Vitest is added to provii-demos/demo-web-provii-agegate as a net-new test harness. The docs gateway vitest suite asserts cross-surface reachability is blocked, includes a 50-variant path-fuzz test against path-traversal attempts, asserts asserts docs cache reads do not mutate playground cache. CI bundle-grep jobs assert prod release artefacts do not include sandbox-only strings or high-entropy base64 blobs of Ed25519-seed shape.

Task: (CI bundle-grep job for prod release artefacts) is PENDING. The Miniflare + Vitest harness is wired but the bundle-grep detective layer that gates prod release is not yet running, so the test-and-acceptance regime for docs gateway secrets leakage is not yet at planned end state.

Requirement: Organisation directs, monitors and reviews activities related to outsourced system development.

Justification: All development is in-house. No outsourced development.

Compensating Controls: If future outsourcing occurs, controls would be established per supplier management procedures

Requirement: Development, testing and production environments separated and secured.

Implementation:

• Development: wrangler dev —local
• Sandbox: —env sandbox for supported Workers
• Production: Cloudflare Workers production environment
• No production secrets in development
• Test data only, never production data

Evidence: Environment configurations, wrangler.toml files

Docs gateway application (planned end state): Sandbox-only endpoints (/v1/register-test-issuer-client and related paths) are gated behind a Cargo feature flag named sandbox_only_register_test_issuer_client (not bare sandbox, to avoid transitive-dep feature-unification collision). A build.rs dual check requires both the Cargo feature flag and CARGO_CFG_PROVII_ENV=sandbox; either condition failing aborts the build. Production deployments reject docs-sbx-* and mwallet-sbx-* client prefixes at middleware level across all request sources. CI bundle-grep on prod release wasm confirms no sandbox strings leak. Docs gateway KV namespaces (DOCS_SESSIONS, SANDBOX_DOCS_ISSUERS, SANDBOX_MOBILE_ISSUERS) are sandbox-only and never bound to production Workers.

Task: (Cargo feature flag sandbox_only_register_test_issuer_client) is DONE. Tasks 0.47 (build.rs + CARGO_CFG_PROVII_ENV=sandbox build assertion), 0.48 (CI bundle-grep on prod wasm), and 0.49 (production middleware rejection of docs-sbx-* / mwallet-sbx-* prefixes across body, path, query, and auth headers) are PENDING. Sandbox / prod separation rests on the Cargo feature flag and KV-binding scope only until the remaining three guards ship; UC-186 in the Unified Control Matrix tracks the end-to-end end state.

Requirement: Changes to information processing facilities and information systems subject to change management procedures.

Implementation:

• Change Management Procedure defined
• All changes via Git and GitHub pull requests
• Branch protection enforces mandatory code review
• CI/CD automated testing validates changes before merge
• Production deployments logged and monitored
• Rollback procedures documented

Evidence: Change management procedure, Git history, CI/CD logs, pull request reviews

Docs gateway application: The docs gateway rollout is recorded in operations/change-management-record.md with evidence for each task. Cross-repo schema changes (for example, the provii-crypto-commons DobAttestation field addition) require a coordinated tag bump across provii-issuer, provii-verifier, and the TS gateway, with golden-vector fixtures regenerated in all three copies. Rollback is supported by per-widget feature flags, a global kill switch, and documented KV-sweep procedures for compromise response.

Requirement: Test information appropriately selected, protected and managed.

Implementation:

• No production data in testing
• Synthetic test data generated
• Test credentials separate from production signing keys
• Separate development environment

Evidence: Test data generation, environment separation

Requirement: Audit tests and other assurance activities involving assessment of operational systems planned and agreed between the tester and appropriate management.

Implementation:

• CI/CD security scans run non-disruptively on every build
• Audit activities scoped and scheduled to avoid production impact
• Read-only access for audit and compliance tooling
• Serverless architecture means audit testing cannot affect production availability

Evidence: CI/CD pipeline configuration, audit scope documentation

Requirement: The organisation acting as PII controller identifies and documents the specific, explicit and legitimate purpose(s) for which PII is processed.

Implementation:

• Purposes documented in ISO 27701 Compliance Statement §A.7.2.1: age verification, abuse prevention, security audit logging, service analytics.
• Purpose limitation enforced architecturally by the zero knowledge design.

Docs gateway application: The gateway introduces a narrow developer-onboarding purpose: allow external developers to exercise the sandbox issuer and verifier APIs through interactive documentation. Documented in security/dpia-docs-sandbox.md and reflected in the updated ROPA. No new end-user processing purpose is created; fixture-ID-only input means no real personal data is accepted from onboarding developers.

Evidence: Docs Sandbox DPIA, ROPA entries for __cf_bm/cf_clearance and __Host-docs_session (see ROPA), Developer Privacy Notice.

Requirement: Legal, statutory and regulatory requirements relevant to PII processing determined and documented.

Implementation:

• Regulatory scope covers GDPR, CCPA/CPRA, COPPA, UK DPA 2018, UK Children’s Code, Australian Privacy Act, and age verification laws.

Docs gateway application: Developer onboarding via the gateway adds a new processing activity disclosed in the updated privacy policy (§2, §3) and covered by a dedicated developer-facing privacy notice. GDPR Art. 35(3)(b) mandatory-DPIA criteria are not met for this surface; a DPIA is performed as good practice. A Children’s Code Standard 2 DPIA assesses child impact under the ICO Age Appropriate Design Code.

Evidence: Updated Privacy Policy, new Developer Privacy Notice, Docs Sandbox DPIA, Children’s Code Standard 2 DPIA.

Requirement: Privacy impact assessment conducted where applicable.

Implementation:

• Existing DPIA at security/dpia.md covers the production verification flow.

Docs gateway application: Net-new DPIA at security/dpia-docs-sandbox.md covers the docs gateway. Scope includes session cookie issuance, shared sandbox issuer identity rotation, and interaction with Cloudflare bot protection cookies (__cf_bm, cf_clearance). A separate Children’s Code Standard 2 DPIA at compliance/standards/childrens-code/dpia-children.md assesses child impact across five age bands (under-5, 5-9, 10-12, 13-15, 16-17), with an explicit fixture-ID-only input posture, real-DOB rejection, and zero-retention SLA for any DOB-shaped payload.

Evidence: DPIA document pair referenced above; ICO age-appropriate-design-a-code-of-practice-for-online-services.

Requirement: Provide PII principals with clear and easily accessible information identifying the PII controller and describing the processing.

Implementation:

• Existing privacy policy at legal/privacy-policy.md.

Docs gateway application: A developer-facing privacy notice is published at legal/developer-privacy-notice.md because developers onboarding via the gateway are themselves data subjects. The main privacy policy gains a sandbox developer-onboarding processing activity under §2 and §3, with version bump and updated “last updated” date. The cookie policy at legal/cookie-policy.md discloses the strictly-necessary __Host-docs_session cookie alongside the existing __cf_bm and cf_clearance disclosures.

Evidence: Privacy Policy (version bump), Developer Privacy Notice (new), Cookie Policy (amended).

Gap: Developer privacy notice requires legal counsel review before production launch.

Requirement: Ensure PII is accurate, complete and up to date.

Implementation:

• Zero-PII architecture eliminates most accuracy burdens.

Docs gateway application: Fixtures returned by GET /api/fixtures have dob_days computed fresh per request to guard against time drift; 11 named synthetic test users are authoritative. Real-DOB submissions to /v1/register-test-issuer-client are schema-rejected and logged as suspicious, preventing accidental accuracy obligations for personal data developers might submit in error.

Evidence: src/docs/fixtures.ts, schema validation on /v1/register-test-issuer-client, COPPA safe harbor synthetic-only posture at compliance/standards/coppa/coppa-safe-harbor.md.

Requirement: De-identify or delete PII at the end of the processing period.

Implementation:

• Audit logs retained 90 days then deleted; critical security event logs are retained for up to 365 days.
• Challenge state expires after 5 minutes.

Docs gateway application: Docs gateway state is subject to a retention schedule documented in security/data-retention.md: __Host-docs_session cookie TTLs (15-min sliding bearer, 4-hour hard cap), docs-cred-v:* and docs-cred-i:* (1-hour credential cache), docs-chal:* (24-hour challenge), and mwallet-sbx-* (7-day mobile install). All fall under the 90-day audit retention ceiling.

Evidence: security/data-retention.md, KV TTL configuration in src/docs/handler.ts.

Requirement: Ensure temporary files created during PII processing are disposed of following documented procedures.

Implementation:

• Worker isolates are ephemeral; no disk-backed temporary files.

Docs gateway application: Gateway-side coalescing via caches.default keyed on challenge ID uses a 2-second edge cache TTL (30 seconds for terminal states). No persistent temporary artefacts are created. The attestation Ed25519 seed is held only within the AttestationSigner closure and never materialised as a JS string, preventing incidental temporary-file or log leakage.

Evidence: Gateway handler source, AttestationSigner implementation at src/docs/attestation-signer.ts.

Requirement: Retain PII only as long as necessary for identified purposes.

Implementation:

• 90-day audit retention (critical security event logs retained for up to 365 days), 5-minute challenge state, no persistent PII.

Docs gateway application: Gateway retention is bounded as above. Session state expires on hard cap (4 hours) even with continued activity. The revocation KV list has a 30-second cf.cacheTtl, bounding poll-endpoint revocation lag without extending retention.

Evidence: security/data-retention.md (amended), KV TTL configuration, revocation runbook.

Requirement: Dispose of PII through secure means.

Implementation:

• KV auto-expiry and cryptographic erasure on encrypted storage.

Docs gateway application: Compromise response for the shared sandbox issuer identity is a documented “nuke all docs-sbx-* and mwallet-sbx-*” KV-sweep procedure exercised quarterly, supplementing the standard quarterly rotation cadence. Worker isolate state is discarded on each cold/warm transition; no disk persistence survives a redeploy.

Evidence: Rollback runbook (in tracker), incident response playbook updates.

Requirement: Identify and document the legal basis for any cross-border PII transfer.

Implementation:

• Cloudflare master DPA covers cross-border transfers under Standard Contractual Clauses.

Docs gateway application: The gateway introduces Cloudflare Bot Fight Mode, Super Bot Fight Mode, Rate Limiting API, Cloudflare Workers Logs, and R2 as processing components. Workers Logs are forwarded to Grafana Loki (Grafana Cloud) for operational observability. All Cloudflare components are operated under the existing Cloudflare master supplier relationship and are enumerated in a sub-processor list at legal/sub-processors.md, cross-linked from DPA templates. A DPA addendum for the docs gateway scope is published at legal/dpa-docs-sandbox-addendum.md.

Evidence: legal/sub-processors.md, legal/dpa-docs-sandbox-addendum.md, existing Cloudflare DPA and SCC references.