| name | security-page-design |
| description | Use when designing a dedicated /security page. Covers what to include (data classification, encryption, certifications, sub-processors, incident response), the tone, and how to balance technical detail with reassurance.
|
Security Page Design
A security page reassures security-conscious buyers without scaring novice buyers. Get both audiences.
Canonical sections
Data classification · Encryption (in transit + at rest) · Authentication · Compliance certifications · Sub-processors · Incident response · Bug bounty (if any) · Contact for security inquiries.
Tone
Confident, specific, plain English. NOT marketing language. NOT defensive.
Specific over generic
'TLS 1.3 + AES-256 at rest' beats 'bank-level encryption'. 'SOC 2 Type II audited annually' beats 'enterprise-grade security'.
DPA + sub-processor list
Link to your DPA. Public list of sub-processors with what each does (e.g., Stripe — payment processing). Enterprise buyers need this.
Common mistakes
Vague claims. Logos of every security framework without actual certification. No contact email for security inquiries. No date stamp on the page.
Where this fits in X3 Compass
Applied in the X3 Compass build via the relevant pages and components.
