Security posture
A description of practices, not a certification, published so it can be inspected and argued with.
What follows describes practices, not a certification, and the difference is worth stating before anything else. No audit has been performed against these, no attestation exists, and nobody has been paid to verify them. They are what is done, written down so somebody can inspect them and disagree.
The amount of third-party software is a security decision before it is a performance one. Every package is code executing with the application's privileges, maintained by somebody unknown, and the realistic attack on a small business is not a targeted intrusion — it is a compromised package somewhere in a tree nobody has read.
Sites built here are static output wherever the work permits it. No database, no administrative login, no plugin ecosystem, and no upgrade path that can be exploited. The attack surface that arrives as standard with a content management system is not defended against; it is absent.
Everything a client can send is validated on the server, and client-side validation is treated as a convenience for honest users, not a control. Anything else assumes the request came from the form instead of from whoever chose to construct it.
Credentials live in configuration and never in the code itself, and access to live systems is separated from access to the work.
Administrative surfaces are behind real authentication from the first commit, not added once the data becomes sensitive. A tool that begins life on an unguarded URL because it is only internal for now will still be on an unguarded URL in two years, holding considerably more.
Transport is encrypted everywhere with no exceptions for pages that seem unimportant, since the exception is where the session cookie travels.
Where a genuine adversarial assessment is warranted, it is a separate engagement with a specialist firm, and saying so is part of the work. Penetration testing is a discipline, not a checklist item, and pretending a code review substitutes for one is exactly the kind of claim we refuse to make.
None of the above amounts to a security program for an organization with real adversaries. It is proportionate to the systems described elsewhere here, and a business whose risk profile exceeds it should be told that plainly rather than sold reassurance.
What this does not cover.
- Certification or attestation of any kind. No claim is made to SOC 2, ISO 27001, HIPAA, or PCI compliance.
- Penetration testing and offensive security engagements.
- Security monitoring or incident response for systems built by others.
Security & Compliance
Claims and their disclosures
A claim and its required condition are one object, so a claim whose disclosure is missing cannot be rendered at all.
Data handling
The design question comes before the security question: a field that was never collected cannot leak, be retained too long, or turn up in a log.
Secrets and configuration
A credential committed alongside the code has been distributed to everyone who has ever taken a copy, and deleting the file does not retrieve it.
Input and trust boundaries
Anything arriving from a browser was composed by whoever is sitting there, not by the form that was designed.
Sources and verification
A requirement drafted from general knowledge reads exactly like one drafted from the statute, so the source and the date are stored as fields.
Subprocessors
Every third party a system talks to holds part of what customers hand over; the list is short by design and written down.