REF SEC — PLATFORM ASSURANCE
Built to survive your security review
Most construction marketing agencies have never seen an enterprise vendor security questionnaire. We complete them as a matter of routine. This page is the platform posture your IT and procurement teams will ask about — in their language, with nothing hidden.
For IT and procurement teams: everything below describes the standing architecture every BoxBuild client runs on — commercial GCs, industrial and manufacturing builders, data-centre and healthcare contractors, large specialty trades and suppliers.
THE SHORT ANSWER
Hosting & infrastructure
A custom application on isolated infrastructure — not a theme on shared hosting.
Custom Next.js + Payload CMS build
Every client runs a custom application — React front end with a self-hosted headless CMS. No themes, no marketplace plugins, no shared codebase with strangers.
Isolated, containerised instances
Application and PostgreSQL database run as isolated, containerised instances per client. No shared hosting, no co-tenants on your stack.
Independently attested providers
Railway (SOC 2 Type II), Supabase (SOC 2 Type II, ISO 27001), Cloudflare (SOC 2 Type II, ISO 27001), and GitHub (SOC 2 Type II) hold current attestations for the layers they operate, available through their trust centres.
Separated environments
Development and production are separate environments with separate credentials — changes are built and reviewed away from the live site, then deployed through version control.
Access & authentication
Least privilege, individually named, nothing shared.
MFA on infrastructure accounts
Multi-factor authentication is enforced on every account that touches client infrastructure — hosting, DNS, database, and source control.
Individual named accounts
Role-based access on least privilege. People get the minimum access their role requires under their own named account — no shared logins — and access is revoked when the role ends.
CMS access control
The CMS admin is restricted to individually named, authenticated accounts; machine integrations use scoped API keys rather than human credentials.
Encrypted secrets
Credentials and API keys live as encrypted environment variables in the hosting platform — never in source control, never in tickets or chat.
Application security
The most common website compromise vector — the plugin ecosystem — does not exist here.
No third-party plugin ecosystem
No WordPress, no theme marketplace, no plugin supply chain. The single most common source of website compromise is removed by architecture, not by patching.
Critical patches within 48 hours
Critical security patches are applied across the stack within 48 hours of release. Dependencies are version-locked through the package lockfile and audited.
Injection and XSS defences
Database access is through an ORM with parameterised queries (SQL injection); output is escaped by the React rendering layer and constrained by a Content Security Policy (XSS).
Reviewed changes only
Every change flows through Git-based review before deployment. Third-party scripts are reviewed before inclusion — the CSP allowlist names each permitted origin.
Network & data protection
Filtered at the edge, encrypted in transit and at rest.
WAF + DDoS mitigation
A Cloudflare web application firewall with Layer 3/4/7 DDoS mitigation sits in front of every request before it reaches the application.
Modern TLS, site-wide
TLS 1.3 preferred and TLS 1.2 minimum on every route, with HSTS enforced so browsers never downgrade to plain HTTP.
HTTP security headers
Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy are set on every response.
Encryption at rest — and no lead PII stored
Database and media storage are encrypted at rest (AES-256). Form submissions are forwarded to your CRM and never persisted in the website database — there is no at-rest store of lead PII on the web stack.
Backups & continuity
Tested restoration, not just scheduled backups.
Daily encrypted backups
Automated daily database backups, encrypted in transit and at rest, held separately from the application tier.
Version-controlled source
All source code is version-controlled and mirrored — the application can be rebuilt from the repository at any time.
Tested restoration
Restoration procedures are exercised on a scheduled basis — a backup that has never been restored is a hope, not a plan.
Rapid rollback
Deployments are atomic and reversible: the platform can return to a known-good state quickly if a release misbehaves.
Logging & incident response
Watched continuously, with a notification commitment in writing.
Event logging with retention
Administrative, privilege, and authentication-failure events are logged across the hosting, database, and edge layers, with retention for review.
Uptime & error monitoring
Availability and application errors are monitored continuously, with alerting to a person who can act — not a dashboard nobody reads.
24-hour breach notification
If an incident affects your data, your incident-response contact hears it from us within 24 hours of confirmation — with specifics, not generalities. The SLA can be set to your own corporate standard.
Ownership & governance
Your asset, your accounts, your exit path.
You own everything
Code, content, database, and assets belong to the client — always. Domains stay in your own registrar account; we never hold them.
Non-proprietary stack
Next.js and Payload are open, widely adopted technologies. Any competent engineering team can take over the codebase — no vendor lock-in by design.
Clean handover path
Documented setup, exportable content, and infrastructure accounts you can audit. Leaving is deliberately easy — which is why clients stay.
Optional enhancements
For organisations with their own identity and monitoring standards.
Corporate SSO / SAML
CMS authentication can be federated with your corporate identity provider on request, so admin access follows your own joiner/leaver process.
SIEM log forwarding
Centralised, immutable log forwarding to your security information and event management platform can be configured on request.
What your IT team is actually comparing
| Typical agency WordPress build | The BoxBuild platform | |
|---|---|---|
| Plugin attack surface | Dozens of third-party plugins, each a potential compromise vector | None — no plugin ecosystem exists in the architecture |
| Patch commitment | Best effort, often unowned | Critical patches within 48 hours, in writing |
| Environment separation | Edits on the live site | Separate development and production, deployed via Git review |
| Hosting tenancy | Shared hosting, co-tenants | Isolated containerised instances per client |
| Ownership & exit | Agency-held domains and licences are common | Client owns code, content, data, and domain — documented handover |
| Incident response | Undefined | 24-hour breach notification commitment, SLA settable to your standard |
A NOTE ON CERTIFICATIONS — READ THIS PART
Running a vendor review? We’ll complete your security questionnaire — your format, your timeline. See also Our Stack for the full platform architecture, or get in touch to start one.
Send us your vendor security questionnaire.
We’ll complete it in your format, on your timeline — before you commit to anything.