Security & Compliance
Security questions arrive early in a serious engagement, usually from a procurement or InfoSec reviewer who has heard vendor security pitches before. What follows states the operating practices plainly: how access is granted and removed, how code gets reviewed and how an incident receives a response. Data handling is designed around recognised privacy expectations from the first architecture diagram, not assumed after the fact.
Access is granted narrowly and removed fast.
Every engineer receives the minimum system access their current task requires, reviewed against a fixed schedule rather than left to accumulate over a project's life. Access to a client's production environment is logged and time-boxed wherever the client's own tooling supports it. When a person rotates off an engagement, their access is revoked the same day, not at the next scheduled review.
What sits with us and what always stays yours
A security reviewer usually wants one map, not four separate policies: which surface we touch, what we do with it, and what never leaves your control. Each row states that boundary for the areas a diligence process checks first, with no surface shared unless a client decision put it there.
| Surface | Our practice | What you retain |
|---|---|---|
| Source code access | Engineers work inside your repository under your permission model | Ownership and hosting decisions, set by your own agreement |
| Production data | Touched only where a task requires it, never copied out | Full control over where it lives and who else sees it |
| Deployment credentials | Held only for the duration a task actually needs them | The ability to revoke or rotate any credential at will |
| Incident decisions | We propose a fix and a timeline for your sign-off | The final call on any client-facing communication |
| Offboarding | Access removal starts the day a person leaves the engagement | Confirmation that every credential and repository link was closed |
Security review happens before merge, not after launch.
Security review is a workflow habit rather than a checklist run once before launch. Peer review, dependency scanning, secrets management and environment separation run continuously through every sprint, catching the mistakes that a single late-stage audit tends to miss entirely. None of the four steps is optional for the sake of a deadline.
01Check onePeer review on every change
A second engineer reviews each change before it reaches the main branch, checking logic and looking specifically for common security mistakes.
02Check twoAutomated dependency scanning
Third-party libraries are scanned on a recurring basis so a known vulnerability in a dependency is caught before an attacker finds it first.
03Check threeSecrets stay out of source control
Credentials and keys live in a managed secrets store rather than in a repository, removing the single most common cause of an accidental exposure.
04Check fourStaging mirrors production risk
Sensitive data is masked or synthetic in non-production environments, so a testing mistake cannot expose a real client record.
A named owner responds before the clock resets.
An incident response plan is only useful if it survives contact with an actual bad night, which is why the plan here is short, written and rehearsed rather than aspirational. A named owner takes the first call, the client is told directly rather than after the fact, and the closing review changes something concrete about how the next sprint runs.
One documented escalation path
Every engagement has a written escalation path naming who is contacted first, so nobody wastes the opening hour deciding who to call.
Client notification is not optional
A confirmed incident affecting client data triggers direct notification to the client contact, not an internal-only fix followed by silence.
A written post-incident review
Every incident closes with a written review of cause and fix, feeding back into the review checklist so the same gap is not repeated.
Read what sits either side of this practice.
Security practice is one part of a wider trust picture a diligence process usually assembles. These three routes carry the credential status, the client voice and the direct channel a security reviewer typically needs next.
Check the frameworks under active audit
The credentials record lists which information-security and quality frameworks are formally under evaluation right now.
Hear how a regulated client assessed us
Client evidence carries the practical read of these practices from someone who put them through their own security review first.
Send your own security questionnaire
A completed vendor security questionnaire routes fastest through a direct conversation with a named engineer rather than a general enquiry queue.
Practices confirmed by the people who audited them.
The standard for this practice is a named client willing to describe the review in their own words, alongside the frameworks currently under audit. These previews hold that shape while signatures and results are confirmed.
Explore case studiesA standing access-review discipline runs across every engagement, closing gaps before they turn into an incident.
- Access reviews
- Every quarter
- Leaver access removal
- Same day
Scope and control mapping are complete; the external audit is scheduled next, with results publishing once confirmed.
Sample · pending client approvalContract templates covering retention, sub-processing and breach notification are in legal review ahead of publication.
Sample · pending client approvalTheir security review of our own codebase found real issues before our next audit even started.
Sample · pending client approval
Questions a security reviewer asks first.
01Do you sign a non-disclosure agreement before any technical discussion?
Yes, a mutual non-disclosure agreement is standard practice before any codebase, architecture diagram or sensitive business detail is shared in either direction. It is offered as a default step in the first conversation, not something a client has to request or negotiate for.
02Where is client data physically stored during an engagement?
Wherever the client's own architecture and hosting decisions place it, since engagements typically work inside a client's existing cloud environment rather than a separate ValueCoders-owned system. Data residency and hosting region are treated as the client's decision, documented at project start rather than assumed by default.
03What happens to source code and credentials once a project ends?
Access is revoked and locally cached credentials are deleted from engineer machines as part of the standard offboarding checklist, not left for someone to remember later. Source code ownership follows the terms agreed in the engagement contract, and repository access outside that agreement ends with the project.
04Can an engagement work entirely inside our own infrastructure?
Yes, and it is a common request from clients in regulated sectors, who prefer engineers to operate entirely inside infrastructure they already control and monitor. In that model, our own systems hold nothing more sensitive than project management and communication records.
05How quickly are you notified of a new vulnerability disclosure?
Dependency scanning runs on a recurring schedule rather than waiting for a manual check, so a newly disclosed vulnerability in a used library is usually flagged automatically within the same cycle. A flagged dependency is triaged and patched according to its severity, with the client informed when client-facing systems are affected.
06Do your engineers use AI coding tools on client codebases?
Only where a client has agreed to it, and only inside the boundaries that agreement sets. Client code and data are excluded from a tool's default training pathways under the agreements in place, and every case runs through the same review gates as human-written code before it merges.
07Who do we contact if a security concern is found after delivery?
The named engagement contact from the delivery period remains the first point of contact, and the escalation path stays active for a defined post-delivery window agreed in the contract. A concern raised outside that window is still triaged, just through the general contact channel instead of a dedicated one.