Security and data handling
Practices that can be checked, not badges
This page describes how work is actually built and operated. It makes no compliance claims, because none are held. Everything below is something you can ask about during an engagement and verify in the delivered code and documentation.
Design practiceLimitation
Stated plainly
What is not claimed
Certification language is common in this market and easy to imply. None of the following is held, and none is claimed.
Not held, not claimed
- SOC 2 (Type I or Type II)
- ISO/IEC 27001
- CMMC at any level
- ITAR or EAR registration or readiness
- HIPAA, PCI DSS or any other formal compliance programme
Practice
Control over what reaches a customer
The strongest control in this kind of work is not technical. It is deciding, in advance, which actions a workflow is never allowed to take on its own.
- Human approval on prices and commitments
- Anything involving a price, a delivery promise or a customer-facing message is approved by a named person before it is sent. This is built into the workflow rather than left as a configurable option.
- Confidence thresholds route to people
- Where a classification or a customer match is uncertain, the item goes to a review queue. A low-confidence result is never treated as a decision.
- Narrow first deployments
- Go-live is normally limited to one customer, category or branch, then widened once behaviour has been observed against real traffic.
Practice
Access and credentials
Access is kept as small as the workflow allows, and it stays under the client’s control.
- Least-privilege scopes
- Integrations request only the permissions the workflow needs. Read-only access is used wherever a write is not required.
- Client-created credentials
- Credentials are created by the client in the client’s own accounts wherever practical, so they can be revoked at any time without depending on anyone else.
- Managed secrets
- Secrets live in the platform’s secret storage or a managed secrets service. They are not committed to repositories, pasted into chat, or stored in documents.
- Separate credentials per environment
- Test and production use different credentials, so testing cannot reach production data by accident.
Practice
Data handling
The aim is to hold as little as possible, for as short a time as the workflow permits.
- Minimal logging
- Logs record what happened and whether it succeeded. Message bodies, attachment contents and personal data are not written to logs as a matter of routine.
- Agreed retention
- Retention for any queue or working store is agreed in writing during scoping, and the deletion mechanism is part of the build rather than a promise.
- Data stays in client systems
- Wherever the design allows, records stay in the systems the client already owns instead of being copied into a new store that then has to be secured and maintained.
- Restricted categories are refused
- Export-controlled technical data, controlled unclassified information and similar categories are not accepted through the public form or the demonstration, and are out of scope unless a proper compliance arrangement exists.
Practice
Reliability engineering
Integrations fail. The design question is what happens next, and whether anyone finds out.
- Idempotency
- Writes carry a stable key derived from the source record, so a retried or duplicated delivery updates the existing record instead of creating a second one.
- Retries with backoff
- Transient failures are retried with increasing delays and a ceiling. Permanent failures stop immediately and go to the error queue rather than retrying forever.
- Error queues
- Anything that fails lands in a queue with the reason and enough context to act on, and the queue is visible to the client rather than only to the developer.
- Audit trails
- Each item carries a record of what arrived, what was extracted, what was proposed, who approved it and what was written.
- Rate-limit handling
- Integrations respect published quotas and back off when throttled, so one busy morning does not get the client’s account suspended.
Practice
Deployment and reversibility
Every change should have a way back that was written before it was needed.
- Shadow mode before go-live
- The workflow runs against real traffic and produces proposed output while the manual process continues. The two are compared before anything depends on the automation.
- Documented rollback
- A rollback procedure and its trigger are agreed before go-live, not written during an incident.
- Handover documentation
- Runbooks, configuration notes, failure modes and credential locations are delivered as part of the work, and the client owns all of it.
This website
How this site itself is built and what it processes
A security page that ignores the site it is published on is not worth much.
Site controls
- Third-party code
- The site loads no third-party scripts, fonts, frames or trackers. Fonts are self-hosted. There is no analytics, no tag manager, no session recording and no heatmap.
- Headers
- A Content-Security-Policy is served in report-only mode while it is verified against the real build, alongside strict transport security, nosniff, a referrer policy, a restrictive permissions policy and frame-ancestors none.
- Form handling
- Server-side validation is authoritative, the request method and content type are checked, the body size is capped, and a honeypot and submission-timing check run before anything else.
- Logging
- Form contents are never written to application logs. The hosting provider processes IP addresses and request metadata as part of serving the site.
- Storage
- There is no database, no account system and no cookie set by this site. Submissions are delivered by email and are not retained by the application.
Subprocessors for this website
- Hosting provider
- Serves this website and runs the contact form endpoint. Processes IP addresses and request metadata as part of normal operation.Cloudflare Workers is the intended host. This page will be updated if that changes before launch.
- Transactional email provider
- Delivers the notification of a form submission and the acknowledgement sent back to the sender.Resend is the documented default. The integration is provider-neutral and the provider in use will be named here once it is live.
- Domain and DNS provider
- Resolves the domain and holds the email authentication records.Cloudflare. The domain alloypathsystems.com is registered through Cloudflare Registrar, and Cloudflare provides the authoritative DNS for it.
The privacy notice covers what the contact form collects, why, and how long it is kept.
Request a workflow review
Bring your security questions to the review
Access scopes, credential ownership, logging and rollback are reasonable things to interrogate before any access is granted. They are easier to answer against a specific workflow than in the abstract.
30-minute review. You receive a concise written recap. No obligation.
Engagement capacity is intentionally limited so discovery, implementation and handover remain founder-led.