State a few specific practices you really run: how you inventory dependencies, how you handle vulnerabilities, how researchers can contact you, and who owns the process. Link to evidence where you can. Leave out superlatives, certifications you do not hold, and promises you cannot measure.
Who reads the page
District technology directors, privacy officers, and procurement staff, usually under time pressure. They compare vendors and copy language into their own review notes. A short page with checkable statements beats a long page of adjectives.
CISA's K-12 guidance gives schools a frame: it aims to help them buy products that are Secure by Design, offered as considerations they can raise in negotiations. A page that answers those considerations before they are asked saves everyone time.
A section by section outline
1. How we build. Name the framework you follow, if any, and what you actually do. If you align your process to NIST SP 800-218 (the SSDF), say "aligned to," not "certified," because it is a framework of practices, not a certification.
2. Open source and third party code. State that you keep an inventory of dependencies, how often it is regenerated, and how you review additions. Say what you do about packages that reach end of life.
3. How we handle vulnerabilities. Describe your process in terms a reader can verify: how findings are assessed, who decides, and your general approach to urgent fixes. Only give timeframes you meet.
4. How to report a problem. A monitored email address or form, and what a reporter can expect from you.
5. Customer notifications. How and when you notify schools of issues that affect them, and who receives the notice.
6. Data handling. Where student data lives, who can access it, and your sub-processor list or how to request it.
7. Status of assurance work. If you are working toward an audit or attestation, say that it is in progress, with the type, not that it is complete. Do not imply a certification when the reality is a plan.
Claims to leave out
| Avoid | Say instead |
|---|---|
| "Bank grade security" | The specific controls you operate |
| "Unhackable" or "100% secure" | What you do to reduce and detect risk |
| "Certified" without naming the certifying body and scope | The exact status and date |
| Numbers you cannot trace to records | No number, or a range you can prove |
| Names of customers without permission | Types of customers served |
Keep it current
Date the page. Review it every quarter and whenever your practice changes. A stale page is a risk, since districts quote it back to you.
Pair it with evidence
Offer an inventory excerpt, a policy summary, or a sample report under NDA. Even a short artifact makes a claim concrete.
Quick check
Should we publish our full dependency list?
That is your decision. Some vendors share it under NDA. Whichever you choose, say plainly what you can provide.
How long should the page be?
Long enough to answer the common questions, short enough that a busy administrator reads it. One screen per section is a good guide.
Safeguard's compliance and evidence automation and SBOM generation can produce the records that sit behind such statements.
Sources
Last reviewed: 19 October 2026.
