How we handle your systems and your data

Working with client systems

• We sign a mutual non-disclosure agreement before any detailed technical discussion.
• Access is requested at the minimum level needed, for the period needed, and revoked at the end of an engagement.
• We use named individual accounts. We do not share credentials between people, and we do not accept shared accounts from clients.
• Multi-factor authentication is required on every account with access to client systems.
• Client data stays in client systems wherever the work allows. Where a copy is unavoidable, it is minimised, access-controlled and deleted at the end of the engagement.
• Production data is not used in development or test environments unless it has been anonymised.
• Each client's material is kept separate. We do not commingle client repositories, credentials or documents.

Secure development practice

• Secrets are never committed to source control or placed in configuration files. We use managed identity and a secrets manager.
• Dependencies are reviewed for known vulnerabilities as part of the build, not as an occasional exercise.
• Every material change is peer reviewed before it reaches production.
• Environments are separated, and production changes go through the deployment pipeline rather than by hand.
• Authentication and authorisation decisions are made server-side, and we assume the client is hostile.
• Security requirements are written down at the start of an engagement and tested, rather than assessed at the end.

Artificial intelligence

• We use AI-assisted development tools. Everything they produce is reviewed by the engineer responsible for the change — accountability sits with a person, always.
• Client code and client data are not pasted into tools that have not been approved for that client's engagement.
• Where a client prohibits AI-assisted development, we comply and confirm it in writing.
• AI features we build for clients are evaluated against acceptance criteria agreed before development, and are designed with defined fallback behaviour when the model is unavailable or uncertain.

Operational practice

• Backups are verified by testing the restore, not by confirming the job ran.
• Systems we support have monitoring, alerting and a documented incident response path.
• We maintain an operational runbook for every system we deliver or support, written for whoever inherits it.
• Business continuity does not depend on one individual. Documentation is sufficient for another competent engineer to take over.

Commercial and legal

• Master services agreement, statement of work, mutual NDA and a defined change-order process.
• Intellectual property: you own all client-specific deliverables and your data. Pre-existing WeInDev components are licensed to you perpetually, and the contract distinguishes the two explicitly.
• Contractors are engaged under agreements with equivalent confidentiality and IP-assignment terms.
• Data-processing terms are available where your obligations require them.
• Professional liability and cyber insurance are carried. Certificates are available on request.

This website

• Served as static files over HTTPS with a strict Content Security Policy that permits no inline or evaluated script.
• Form submissions are validated server-side and stored in a database that denies anonymous access by default.
• Analytics are loaded only after consent, and we do not enable advertising-identity features.
• What we collect and how long we keep it is described in the privacy policy.

Questions

If your security team needs something not covered here — a completed questionnaire, specific contractual terms, evidence of insurance — write to hello@weindev.com and we will respond properly rather than with a brochure.