DPIA. Children’s Code Standard 2 (Docs Sandbox)

Assessment Overview

1. Purpose of this DPIA

ICO Standard 2 requires services likely to be accessed by children to undertake a DPIA “specifically in respect of the child safety and data protection risks that might arise” from their processing. The Children’s Code Compliance Matrix concludes that the Code does not directly apply to Provii (an age verification service that excludes children from the relying party content it gates), but the docs interactive sandbox is a separate surface with a separate audience and a separate risk posture. This DPIA assesses whether the docs sandbox creates any child-impact risk and documents the controls that hold that risk to negligible.

The conclusion of this DPIA is that the docs sandbox is not likely to be accessed by children in the ICO sense, accepts only fixture IDs (never raw DOB strings) as inputs that resemble children’s data, rejects any real DOB string at the schema boundary, and operates a zero-retention SLA for any DOB-shaped payload. The DPIA is documented because publishing it is itself a Standard 2 compliance signal.

2. Description of the Processing

Nature

The docs interactive sandbox is the developer onboarding surface attached to docs.provii.app. It exposes:

• A gateway under docs.provii.app/api/* that issues a strictly-necessary __Host-docs_session cookie and brokers calls to the sandbox issuer and verifier APIs.
• Credential generators that mint sandbox-scoped issuer client IDs into the SANDBOX_DOCS_ISSUERS allowlist.
• An in-page API explorer (Scalar) that lets developers exercise sandbox endpoints with bearer tokens scoped to the sandbox.
• A styler iframe at preview.docs-sandbox.provii.app that renders interactive sandbox widgets.

The audience is external developers evaluating or integrating Provii. The surface is publicly reachable, so children could in theory navigate to it. The processing posture for any child-derived data is described in Section 3.

Scope

Data Categories

3. Posture on Child Data. Explicit Statements

The docs sandbox operates the following explicit posture for any input that could relate to a child:

1. The sandbox accepts fixture IDs only. Endpoints that take age-shaped input accept references to one of 11 named synthetic test users (fix-1 through fix-11) and nothing else. Each fixture’s dob_days is computed fresh per request to guard against time drift; the underlying fixtures are not derived from real persons.

2. The sandbox rejects any real DOB string. The /v1/register-test-issuer-client endpoint enforces a schema that rejects:

• ISO 8601 dates (YYYY-MM-DD)
• Free-text date strings parseable as a date
• Integer dob_days values outside the synthetic fixture range Rejected requests return HTTP 400 and are logged as suspicious to the audit retention queue. The rejected payload body is not persisted in the rejection log; only the fact of the rejection, the requesting session ID, and the schema violation code are retained.

3. Zero retention for fixture-input data. Fixture lookups are stateless: the gateway recomputes the synthetic dob_days, builds the attestation, signs it, returns it, and forgets it. No fixture-input lookup is recorded against a session.

4. Sandbox attestations cannot reach production. Sandbox attestations are signed by a disjoint Ed25519 key used exclusively for the docs sandbox, and production middleware rejects docs-sbx-* and mwallet-sbx-* prefixes across body, path, query, and authorisation header. A sandbox attestation built around a fixture ID has no path into a production verification.

5. No child-targeted features. The docs site contains no games, video content, social features, avatars, profiles, content recommendations, or other features designed to attract or retain a child audience.

4. ICO “Likely to Be Accessed by Children” Assessment

The Code applies if a service is “likely to be accessed by children”. The ICO methodology considers the nature of the service, marketing, content, age signals, and prevalence of child users. Applied to the docs sandbox:

Conclusion: The docs sandbox is not likely to be accessed by children in the ICO sense. This DPIA is conducted nonetheless because Maelstrom AI publishes Standard-by-Standard compliance treatment for the Children’s Code and Standard 2 expects a documented, reviewable assessment.

5. Five Age-Band Analysis

The Children’s Code defines five age bands. The analysis below reflects the docs sandbox specifically, not the production verification flow (which is covered in the production DPIA).

5.1 Under-5 (Pre-literate)

5.2 5-9 (Early literacy)

5.3 10-12 (Core primary)

5.4 13-15 (Transition years)

5.5 16-17 (Approaching adulthood)

6. Standard 2 Walkthrough. ICO Requirements

Standard 2 enumerates several specific expectations for a child-focused DPIA. Each is treated below.

6.1 “Address risks specific to children”

The risk treatment of the docs sandbox addresses children specifically by:

1. Refusing real DOB inputs at the schema boundary, which removes the principal child-PII vector before any processing can occur.
2. Operating a zero-retention SLA on fixture-input data, so even a child experimenting with the credential generator cannot create a data trail.
3. Excluding child-attractor features (games, social, avatars, recommendation) from the docs surface entirely.

6.2 “Take into account differing ages, capacities, and developmental needs”

The five-band analysis in Section 5 addresses this requirement directly. The developer privacy notice is written in plain language readable by the 13-15 and 16-17 bands without parental support.

6.3 “Ensure that processing is proportionate to the risks to children”

Processing is minimal. The session cookie is strictly necessary for the developer-requested service; the hashed IP is required for abuse investigation under legitimate interest; no other personal data is retained. There is no processing that exceeds what is required to deliver the developer onboarding service.

6.4 “Consider the rights of the child”

Children retain their full data subject rights even if they access the docs sandbox. The developer privacy notice will discuss rights of access, erasure, and objection, in plain language, with privacy@maelstrom.au as the contact point. Because the only retained data tied to a developer is a hashed IP and a session record, any erasure request can be honoured by KV-sweeping the requesting session and IP-hash bucket.

6.5 “Document the assessment and keep it under review”

This document is published under the Children’s Code section of the ISMS at /trust/standards/childrens-code/dpia-children. It is reviewed annually, on material change to the docs sandbox surface, and on regulatory change. The next scheduled review is April 2027.

6.6 “Consult those affected”

Children are not the intended audience and are not expected to be a material part of the actual audience. As such, formal consultation with child users is not proportionate. The developer privacy notice will invite feedback through privacy@maelstrom.au, and the ICO is the supervisory authority of last resort for any concerns raised about UK child-impact.

7. Risk Treatment Summary (Child-Focused)

No risk in this register exceeds Low residual after mitigation.

8. Conclusion

The docs interactive sandbox is not likely to be accessed by children in the ICO sense, but Maelstrom AI publishes a child-focused DPIA under Children’s Code Standard 2 because this is the discipline the Code expects of any organisation operating an internet-facing surface with even tangential potential for child interaction. The sandbox accepts fixture IDs only, rejects any real DOB string, retains zero fixture-input data, and contains no features designed to attract children. Sandbox-scoped credentials cannot reach production. Hashed IP retention sits under the existing 90-day audit ceiling.

Determination: The docs sandbox satisfies Children’s Code Standard 2 expectations. No additional child-specific controls are required at this time.

Reassessment Triggers:

• Material change to the gateway surface (new endpoints, new cookies, new credential prefixes)
• Introduction of any feature that could attract a child audience (avatars, social, games)
• Any incident touching the schema-rejection boundary for DOB inputs
• ICO guidance update affecting the Standard 2 methodology
• Cross-reference to the production Children’s Code Compliance Matrix on its next review cycle

Document Information