# Trust Center

> Choosing someone to build and secure your systems should turn on evidence rather than adjectives. This page collects what a serious buyer checks before signing: who we are, who is accountable, how the work is produced, what you own when it ends, and what happens when something goes wrong.

**URL:** https://www.regenbyte.com/trust

## Your accounts. Your infrastructure. Your code.

This is a standing commitment rather than a negotiating position. An agency that holds your domain, your hosting or your repository is an agency you cannot leave, and that arrangement benefits us at your expense.

- **You own the source code:** Everything written for you is yours, in your repository, under a licence that does not depend on us. There is no proprietary framework you have to keep paying for.
- **Accounts are created in your name:** Wherever it is practical, the domain, hosting, DNS, cloud, repository, analytics, payment provider and third-party services are set up in your own accounts, with us added as a collaborator rather than as the owner.
- **Access is transferable, not hostage:** Deployment credentials, environment variables and administrative access are documented and handed over. Removing our access should be one afternoon of work, not a negotiation.
- **Documentation written for a successor:** Architecture notes, runbooks and decisions are written so that another competent team could take the system over without speaking to us first.
- **No lock-in by design:** We use widely adopted, well documented technology and avoid decisions whose main effect is to make us hard to replace. Choosing to stay with us should be a judgement about the work.
- **Maintenance is optional:** Ongoing support is offered because systems need it, not because your site stops working without us. Some clients take delivery in house, and we hand over documentation for exactly that.

## How the work is actually produced.

- **Version control and review:** All work is tracked in Git and lands through pull requests. Changes are reviewed before they reach a production branch, and the history explains why something changed, not only that it did.
- **Continuous integration:** Type checking, linting and the test suite run on every change. A branch that does not pass does not merge, so a broken state is caught in minutes rather than after deployment.
- **Automated testing where it earns its place:** Tests concentrate on logic that is expensive to get wrong: authentication, authorisation, payments, data integrity. We do not chase a coverage percentage for its own sake.
- **Dependency and configuration review:** Third-party packages are audited and updated as part of routine maintenance. Known-vulnerable components are the most commonly exploited weakness on the web precisely because exploiting them is automated.
- **Secrets kept out of the codebase:** Credentials live in environment configuration, never in the repository. Keys are scoped to a single purpose so one exposure does not become total access.
- **Performance held to a budget:** Core Web Vitals and page-weight budgets are enforced during the build rather than recovered at the end, and we show you the measurements for your own site rather than generic figures.
- **Accessibility checked, not assumed:** Semantics, keyboard operation, focus order and contrast are verified during development, with automated checks backed by manual passes on the paths that matter.
- **Reversible deployments:** Releases are deployed atomically and can be rolled back to the previous known-good build. The ability to undo a release quickly is worth more than the confidence that you will not need to.
- **Backups that have been restored:** Recovery is tested, not assumed. A backup nobody has ever restored is an assumption, and the moment you need it is the wrong time to find out.

## How we treat our own systems, and yours.

- Security headers, HTTPS and transport hardening applied at the framework level so they cover every route
- Least privilege for accounts, tokens and service credentials, with administrative interfaces not left publicly reachable without reason
- Threat modelling during design, while the architecture can still change cheaply
- Testing only ever under written authorisation from the party entitled to grant it, prospective clients included
- Findings rated by real business impact rather than raw scanner severity, with remediation support and retesting included
- A published responsible disclosure policy and a machine-readable security.txt at the RFC 9116 path

### Methodologies we work to

We work to these published methodologies. To be precise about what that means: these are the standards our testing and review follow, not certifications held by the company. We do not claim a formal accreditation we have not been granted.

- OWASP Top 10 and the OWASP Application Security Verification Standard (ASVS)
- OWASP API Security Top 10 for interfaces rather than pages
- The Penetration Testing Execution Standard (PTES) for engagement structure
- NIST guidance on secure development and incident handling
- CIS Benchmarks for platform and server configuration

## Subprocessors

The third parties that process data on our behalf for this website. Each is listed with what it is for and what it can see.

- **Vercel:** Application hosting, edge network and deployments. Request metadata, including IP address and user agent.
- **Neon:** Managed Postgres database and backups. Site content and submitted enquiry records.
- **Resend:** Transactional email delivery for enquiries. The contents of an enquiry you submit, and your email address.

This describes regenbyte.com. Client projects run in the client's own accounts wherever practical, so each engagement has its own providers and its own list, recorded in that project's documentation rather than here.

## What this site collects, and for how long.

- **What is collected:** Only what you enter in the enquiry form: your name, company, email, an optional phone number and country, and what you write about the project. There is no advertising tracking on this site.
- **Why it is kept:** To reply to you and to keep a record of the conversation. Enquiries are stored before delivery is attempted so a mail provider outage cannot lose one.
- **Who can see it:** RegenByte staff who need it to respond, plus the subprocessors listed above in the course of hosting, storing and delivering the message.
- **How to have it deleted:** Email us and we will delete your enquiry and confirm when it is done. You do not have to give a reason and it does not affect anything else.
- **Client project data:** During an engagement we work inside your systems under your access controls. We do not copy production data to our own machines when a redacted or synthetic sample will do the same job.
- **Findings and reports:** Security findings about your systems are confidential to you. They are not published, reused as marketing, or shared with anyone else without your written permission.

## Incident response and continuity.

- **Contain:** Stop the bleeding first: revoke the credential, roll back the release, take the affected path out of service. Diagnosis comes after exposure is limited.
- **Tell you:** You hear it from us, early, in plain language, including what we do not yet know. We would rather send an incomplete update than a late complete one.
- **Restore:** Return to a known-good state from a tested backup or a previous deployment, and verify the restoration rather than assuming it worked.
- **Establish what happened:** Logs and timelines are preserved so the account of the incident is reconstructed from evidence rather than from memory.
- **Fix the cause:** The immediate fault and the reason it was possible are both addressed. A patch that leaves the underlying weakness in place is half a fix.
- **Write it up:** You get a written account: what happened, what was affected, what was done, and what changed so that it is less likely to happen again. No blame, no vagueness.

### Continuity

- Client systems run in client-owned accounts, so our continuity is never a single point of failure for your business
- Code lives in your repository, so a complete rebuild of any environment is possible from what you already hold
- Handover documentation is kept current during the engagement, not written at the end
- Backups are held by the managed database platform and recovery is tested rather than assumed