How we run what we build
How we host, protect and recover the systems we run for clients. Every claim on this page is one we can show you evidence for.
Security Controls
Verified protections for your data.
TLS 1.3 Encryption
Our public sites and client portal negotiate TLS 1.3 by default, and the client portal and this site enforce HSTS so a browser never falls back to an unencrypted connection.
SSH Key Authentication
Administrative logins to our servers accept cryptographic key pairs only; password login is disabled.
No Admin Access From the Internet
Administrative SSH is closed to the public internet on every production server and reachable only over our private mesh network — verified from outside our network, with a control that proves the test could have seen an open port.
SSH Intrusion Prevention
Repeated failed SSH logins are detected automatically and the source address is banned.
24/7 Automated Monitoring & Alerting
Metrics, centralized logs and alert rules on our main production server, plus an outside uptime monitor on a separate network. Each alert path has been tested by forcing a real failure and confirming the alert reached a person by email or text. A dashboard nobody is paged from is not monitoring.
Secrets Management
Credentials are held in a vault outside the code tree and handed to the program that needs them by reference — never typed into a command line, where they would be logged. Stored automation credentials are encrypted at rest under a dedicated key.
Endpoint Detection & Response
Our production Linux servers run an EDR agent reporting to a central manager, with rule-based detection. Coverage is confirmed at the manager — the only place that can prove a host's telemetry is actually being received — and a monitor checks every ten minutes and sends an alert when an agent disconnects.
Encrypted Offsite Backups
Offsite copies are encrypted with AES-256 and 100,000-iteration key derivation before they leave the host, and a separate, locked copy is held with a second, independent storage provider. Recovery is proven, not assumed: every week each backup set is restored from its offsite copy, and a restore test confirmed that a wrong key and a tampered archive are both rejected.
Tested Procedures, Documented Results
We don't just plan for disasters. We test recovery and publish the results.
| Metric | Target | Tested Result |
|---|---|---|
| Recovery Time (RTO) | 4 hours | Full-stack recovery time not yet measured |
| Recovery Point (RPO) | 24 hours | < 24 hours |
Our recovery target is four hours. All four offsite backup sets — automation workflows, client portal, Glyph and the credential vault — have been restored and verified against production data, with zero tables lost. We have not yet timed an end-to-end recovery of the full stack, so we publish no recovery-time figure. When we measure one, it will appear here.
Enterprise-Grade Foundation
Built on established cloud platforms, configured and verified by us.
Who connects
- Visitors and client staff Over TLS 1.3 by default, with HSTS on the client portal and this site.
- Our administrators Server logins (SSH) go over our private mesh network only, and are key-only.
Where it runs
- Production servers Endpoint detection on each, watchdogs that restart failed services, and metrics, logs and alert rules on the main server.
- Managed database A private endpoint, SSL connections and encryption at rest.
How it is kept
- Offsite copy Encrypted (AES-256) before it leaves, held at our hosting provider for 30 days, and restored and checked every week.
- Locked copy At a second, independent provider: locked against change for 30 days, kept for 180.
Who watches
- Outside observer An uptime monitor on a separate network checks our public services from outside.
- A person is alerted By email or text; each alert path was proven by forcing a real failure.
Managed Database
A DigitalOcean-managed database cluster with encryption at rest and maintenance windows handled by the provider. Connections require SSL and use the provider's private network endpoint.
Private Networking
Database connections use a private endpoint rather than the public internet, and administrative access to every production server runs over our private mesh network.
Hardened Containers
On our main production server, no running container is privileged or can reach the container engine's control socket, every one has privilege escalation blocked, and all but one drop every Linux capability — verified against the running containers in July 2026, not just the configuration files that declare it.
Health Monitoring
Container health checks, watchdogs that restart failed services, and an independent observer that checks our services from outside our network.
Enterprise Cloud Platform
We build on DigitalOcean. DigitalOcean holds its own SOC 2 Type II and SOC 3 attestations covering the platform and data centres we run on — those attestations are DigitalOcean's, not ours. Our services sit on its managed database and private-network tiers.
3-Tier Backup Architecture
Automated local, remote and encrypted offsite backups with AES-256 encryption — a 30-day operational retention window backed by an offsite tier kept for 180 days, where each backup is locked against deletion or change for its first 30 days. Every week, each backup set is restored from the off-site copy and checked against the live data, so recoverability is demonstrated rather than inferred from the backup completing.
Policies & Governance
Thirteen documented security policies and procedures, scheduled for review every January.
- Information Security
- Access Control
- Change Management
- Incident Response
- Backup & Recovery
- Data Retention
- Acceptable Use
- Vendor Management
- Risk Assessment
- Funds Transfer Verification
- Content Removal
- Removable Media
- Cardholder Data Intake
Annual Reviews
Three formal reviews, each e-signed with its findings recorded: an access review, a risk assessment and a vendor security review (latest January 2026, next due January 2027). The signed records are available to clients on request. Recovery is evidenced separately, by the weekly restore tests above.
Risk Management
A formal risk register that scores each risk before and after its controls, reviewed as part of the annual risk assessment.
Monitoring & Self-Healing
Systems that watch themselves, restart what fails, and tell a person when they cannot.
Automated Health Checks
Automated checks cover our production services and the servers they run on, and an alert reaches a person by email or text rather than waiting on a dashboard.
Self-Healing Watchdog
Watchdogs check key services on a schedule and restart them automatically when they fail — and page a person when a restart does not fix it.
Centralized Logging
Application, access and system logs from our main production server are collected into central storage, configured to keep 15 months, giving us an audit trail for investigation and accountability.
Outside Observer
An uptime monitor on a separate network checks our public services from outside, so an outage is seen even when the servers themselves cannot report it. Its alert path was proven by forcing a real failure.
Common Questions
Are you SOC 2 or ISO 27001 certified?
While we'd eventually love to achieve these certifications, we don't hold them at this time. What we do hold is the underlying work: documented policies, signed annual reviews, tested restores, and controls we measure rather than assert. We're happy to walk a security team through any of it.
Can you complete our security questionnaire?
Yes. We answer questionnaires from the same measured evidence shown on this page, and we'll tell you plainly where a control is in place, where one is planned, and where a number is an estimate rather than a measurement.
Where is our data stored, and who else can reach it?
In the United States: on our servers and managed database in our hosting provider's New York region, with offsite copies at our hosting provider and a second, independent storage provider, both in US regions. We keep a written inventory of the vendors that receive client data, available on request.
What happens if you have a security incident?
We follow a signed incident response plan with severity classification, defined escalation paths, evidence preservation, and a post-incident review. Our standard data processing agreement commits us to notify an affected client within 72 hours of discovering an incident.
Security questions?
For compliance documentation, security questionnaires, or vulnerability reports.
Contact us
Tell us what you need built
A 30-minute call about your locations, the tools you run and the work you want to stop doing by hand. We'll tell you what we would build and what it would take.