Security
How we handle client systems, credentials and data — during an engagement and after handover — and how to report a vulnerability.
Scope
This page describes our own practices as a studio: how we access your systems, how we build, and what happens at handover. It is not a certification, and we do not claim SOC 2 or ISO 27001. Where a client needs formal assurance, we will say so honestly during scoping rather than implying we have it.
Credentials and access
- Least privilege. We ask for the narrowest access that lets us do the work, scoped to specific systems rather than blanket administrator rights.
- Your accounts, your control. We work through named accounts you create and can revoke, never a shared login. If you remove our access, it is gone immediately.
- Storage. Credentials live in a password manager with multi-factor authentication. They are never stored in code, in a repository, in a spreadsheet, or in email.
- Transfer. Send secrets through a one-time secret link or your password manager’s sharing feature. If you email us a password, we will ask you to rotate it.
- Devices. Full-disk encryption, automatic screen lock, current operating system, and no client data on removable media.
Client data
We use production data only where the work genuinely requires it, and prefer anonymised or synthetic data for development and testing. Where we must handle real records, we take the smallest extract that answers the question and delete it when the task is done.
Client data is not copied to personal accounts, not used to train anything, and not shared with third parties except the subprocessors named in an engagement’s data processing agreement.
How we build
- Encryption. HTTPS everywhere, encryption at rest for databases and backups.
- Authentication. Hashed passwords using a current algorithm, multi-factor available, sensible session expiry, brute-force limits on login.
- Authorisation. Permissions checked server-side on every request, not hidden in the interface and trusted client-side.
- Input handling. Parameterised queries, output escaping, upload type and size limits, and CSRF protection on state-changing requests.
- Dependencies. Conventional, maintained libraries, kept patched, with automated alerts for known vulnerabilities.
- Audit trails. Who changed what and when, for records that matter — the first thing anyone wants after an incident.
- Backups. Automated, encrypted, and restore-tested rather than assumed to work.
Payments and sensitive data
We do not store card numbers. Payments go through an established provider — the card details never touch your server, which keeps your PCI DSS obligations to the lightest tier.
Where a build touches health records, legal files or other regulated data, we design for the applicable regime, document what is stored where, and recommend you have your own compliance adviser review it before launch.
Incidents
If we become aware of a security incident affecting your systems or data, we will contact you without undue delay and in any case within 24 hours of confirming it. You will get what we know, what we do not yet know, what we are doing, and what we recommend you do.
We will not delay notification to finish investigating, and we will not minimise it. Where a regulator or your customers must be told, we will help you prepare that notification.
Reporting a vulnerability
If you find a security problem in this website or in software we have built, email hello@nexusmind.dev with enough detail to reproduce it. Please give us a reasonable window to fix it before publishing.
We will acknowledge within 2 business days, tell you our assessment and expected timeline within 5, and confirm when it is fixed. We will credit you if you want the credit. We do not run a paid bounty programme, and we will not threaten legal action against anyone who reports a genuine issue in good faith.
Handover and offboarding
At the end of an engagement we hand over repository ownership, hosting and third-party account access, documentation, and a written note of every credential you should rotate. We then remove our own access unless you authorise named access for an agreed ongoing support arrangement. You retain control and can revoke that access.
We keep project correspondence and records for the period stated in the privacy policy, and we delete client production data from our own devices and accounts within 30 days of handover unless you ask us to retain it for support.
Security is mostly unglamorous discipline. If you want to talk through how a build would handle your data before committing, that is a good use of the first call.
Request a 30-min call →