Skip to content

Trust Center

Trust Center

The things you would otherwise have to ask for.

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.

Talk to UsSecurity and Disclosure
Company

Who you would be contracting with.

Entity details are published as they are confirmed. A field left blank here is a field we have not yet been able to state precisely, not one we are withholding: for procurement or supplier onboarding, ask and we will send the full details directly.

Trading as
RegenByte
General enquiries
[email protected]
Security reports
[email protected]
Working languages
English, Arabic, French
Leadership

Named, not anonymous.

You should know who is responsible for the security work you are buying. Full roles and remits are on the About page.

  • Fahad Faisal

    Founder and Chief Executive Officer

    Sets the technical direction of the company and is accountable for how engagements are scoped, how work is delivered, and for the written authorisation that has to be in place before any security testing begins.

See the team →

Ownership

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.

Where a client asks us to host or administer something on their behalf, that is recorded in writing along with what it would take to move it back.

Engineering standards

How the work is actually produced.

These are the mechanics behind the delivery claims made elsewhere on this site. They are ordinary professional practice, which is the point: consistency prevents far more incidents than novelty does.

  • 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.

Security

How we treat our own systems, and yours.

The full policy, including the responsible disclosure terms and what to expect after you report something, is on the security page. This is the summary.

  • 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
Read the security policy →Report an Issue →
Infrastructure

Where this website runs, and who else can see its data.

Listing the tools we use would tell you nothing. What follows is how this website is actually operated and which third parties process data on our behalf.

Request path

  1. 01

    Visitor

    A browser requests a page over HTTPS.

  2. 02

    Edge network

    The request is served from the nearest edge location, with static assets and cached pages returned without touching the application.

  3. 03

    Application

    Pages are rendered on the server, so content is present in the initial HTML whether or not JavaScript runs.

  4. 04

    Database

    Content and enquiries are stored in a managed Postgres database reached over an encrypted connection with scoped credentials.

  5. 05

    Email delivery

    Enquiries are recorded first and then delivered by a transactional email provider, so a provider outage costs a copy rather than the enquiry.

  6. 06

    Backups and monitoring

    Data is backed up by the managed database platform, and deployments, errors and availability are monitored through the hosting platform.

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.

ProviderPurposeData processed
VercelApplication hosting, edge network and deploymentsRequest metadata, including IP address and user agent
NeonManaged Postgres database and backupsSite content and submitted enquiry records
ResendTransactional email delivery for enquiriesThe 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.

Data handling

What this site collects, and for how long.

The full detail is in the privacy policy. This is the short, honest version.

  • 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.

When something goes wrong

Incident response and continuity.

Every system has a bad day eventually. What separates suppliers is what happens in the hours after, so this is the sequence we follow rather than a promise that nothing will happen.

  1. 01

    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.

  2. 02

    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.

  3. 03

    Restore

    Return to a known-good state from a tested backup or a previous deployment, and verify the restoration rather than assuming it worked.

  4. 04

    Establish what happened

    Logs and timelines are preserved so the account of the incident is reconstructed from evidence rather than from memory.

  5. 05

    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.

  6. 06

    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
Documents

Policies and machine-readable endpoints.

Everything above, in the form a lawyer, a procurement team or a crawler would want it.

Machine-readable

  • security.txt

    RFC 9116 security contact and policy location.

  • llms.txt

    An index of this site written for AI assistants.

  • sitemap.xml

    Every indexable URL, in all three languages.

Security questionnaires and supplier onboarding

If your procurement process needs a completed security questionnaire, a data processing agreement, insurance details or entity documents, send it to us and we will complete it. We will answer what is true and leave blank what is not, which is usually faster than it sounds.

Request the pack →

Still want to check something?

If there is a question this page does not answer, ask it directly. A supplier that cannot answer questions about its own practices is telling you something.

Ask a QuestionCybersecurity Services