Red: Protected Build Checklist#

A Protected Build has the highest stakes. The brief must be thorough — explicitly state what protected data you are handling, who your users are, and what compliance requirements apply.

Use version-controlled repositories with access controls. You must be able to track every change and roll back if needed.

Test with data representative of your actual users. If your users are students aged 14-18, test with inputs typical of that age group.

1. Test with names, characters, and input patterns your actual users would produce 2. Test with empty fields, maximum-length inputs, and special characters 3. Test on the devices your users actually have (not just your development machine) 4. Test with data volumes you expect in production

Walk through every "done" criterion. For protected builds, partial delivery is not acceptable.

Exposed secrets in a protected build can lead to a data breach affecting vulnerable users.

1. Search your code for: sk-, api_key, secret, password, token, DATABASE_URL 2. Search your git history for accidentally committed secrets 3. If any were ever committed, rotate them immediately (get new keys/passwords) 4. Use a secrets scanner if available

The kill switch must be documented, tested, and known to at least two people. Document it in your incident response plan.

Fresh eyes catch problems you cannot see.

Full prompt documentation is essential for auditing and maintenance.

Users interacting with protected data need to trust that the tool is legitimate and official.

First line of review before the more thorough technical and designated reviews.

Protected data breaches have legal, financial, and reputational consequences.

1. List every piece of personal or protected data your tool collects 2. Confirm HTTPS is active (lock icon in browser) 3. Confirm database encryption is enabled 4. List every external service that receives data — all must be on the Approved Tools list

Access control failures in protected builds can expose vulnerable users' data.

1. Create two test accounts 2. Verify that Account B cannot access Account A's data through the interface, URL manipulation, or API 3. Test role-based access: can a regular user access admin features?

Technical review catches security and data handling issues before the designated reviewer sign-off.

Technical errors can reveal system architecture to attackers and confuse vulnerable users.

Children and young people have special legal protections. Non-compliance can result in significant fines and reputational damage, and — most importantly — can harm the people you are trying to serve.

1. List every piece of data collected about users under 18 2. For each: is it strictly necessary? If not, remove it 3. Confirm: no behavioural tracking or profiling of minors 4. Confirm: no data shared with third parties beyond what is strictly necessary 5. Check Springpod's policy on parental notification 6. Document your findings for the designated reviewer 7. See the Security Standard for the full requirements

When something goes wrong, you do not have time to figure out what to do. A plan means you respond in minutes, not hours.

1. Use the Incident Report template as your starting point 2. Fill in: first responder name, emergency contact, kill switch instructions, notification list 3. Test the kill switch — actually do it in a test environment to confirm it works 4. Share the plan with at least two people 5. Store it somewhere accessible (not only in the tool itself — if the tool is down, you still need the plan)

Protected builds require accountability. Someone with the authority and expertise to evaluate compliance and safety must explicitly approve the launch. This is not a formality — it is a safeguard for your users.

1. Complete all items above 2. Submit a Review Request to your designated reviewer (see Roles) 3. Include all supporting documents: Build Log, Prompt Specs, third-party services list, incident response plan, privacy compliance notes 4. The reviewer will respond with approval, changes needed, or escalation 5. Record the reviewer's name and approval date

Tools change after launch. Users behave differently than expected. Data volumes grow. A re-intake catches silent escalations — when a tool has become more risky than originally assessed. Schedule it now, while you are thinking about it.

1. Pick a date: 30 days from launch, or after 100 users, whichever comes first 2. Put it in someone's calendar with a reminder 3. When the date arrives, re-run the Project Intake with current (not original) answers 4. If the build path has changed, follow the new path's checklist