Security & data posture
What VenSoc actually operates, and what it does not hold.
This page exists to answer a security questionnaire honestly. It states the controls that are genuinely in place, names the certifications VenSoc does not hold, and describes how client data is handled. Nothing here is aspirational.
In short
Certifications: the honest position
VenSoc holds neither ISO 27001 nor SOC 2. Both are real, expensive, audited programmes, and claiming either — or claiming one is "in progress" — is a procurement-ending mistake, because the questionnaire asks for a certificate number and an audit period, not a roadmap.
For a firm of this size the useful position is to say so plainly and then show the controls that are actually operated, which is what the rest of this page does. Where a client requires certified suppliers, VenSoc is the wrong supplier and will say so at the first meeting rather than the fourth.
Where a client requires specific controls contractually — access review cadence, breach notification windows, data residency, sub-processor approval — those go into the contract and are honoured as contractual obligations.
Controls that are actually operated
Access to client systems
Least privilege, individually issued, revoked at engagement end
VenSoc requests the narrowest access that allows the work: read-only where reading is enough, scoped service accounts rather than shared administrator credentials, and time-bounded elevation for specific tasks. Credentials are issued to a named individual, never shared, and revocation at the end of an engagement is a written step in the exit checklist rather than something remembered.
Secrets
Never in source control; injected at deploy time
No credential, token, key or connection string is committed. Configuration is read from the environment, with a checked-in example file that contains names and no values. Where a secret has been exposed historically in an inherited codebase, rotation is treated as the fix — removing it from the latest commit does not remove it from the history.
Production data
Not copied to development environments
Development and test environments run on synthetic or anonymised data. Where a production defect can only be reproduced with real data, it is reproduced in the client’s own environment under their controls rather than copied out. Personal data is not pulled into a VenSoc machine to make debugging convenient.
Dependencies
Audited on every build; patched as standing work
Dependency vulnerabilities are checked as part of the build, not as a quarterly review. On this website the audit currently reports zero vulnerabilities, and the framework was upgraded a major version at the start of the project specifically because the scaffolded version shipped three high-severity CVEs. Under a support retainer, patching is standing work rather than a change request.
Application security
Validated at trust boundaries, tested for the negative case
Input is validated where untrusted data enters, queries are parameterised, authorisation is checked at the resource level rather than only at the route, and errors do not leak internal detail. Authorisation tests assert the negative case — the wrong tenant and the wrong role must be refused — because a test that only proves the right user succeeds proves nothing about the boundary.
This website
No analytics, no cookies, no third-party scripts
vensoc.com sets no cookies, runs no analytics, embeds no third-party scripts and loads no external fonts — typefaces are self-hosted, which also removes the GDPR exposure created by serving fonts from a third-party CDN. The only personal data the site collects is what you type into the contact form. Content-Security-Policy, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy are set and asserted by an automated gate on every build.
Intellectual property
Assigned to the client from the first commit
Ownership of code, infrastructure definitions and documentation is the client’s as it is written, not on final payment. VenSoc retains no licence-back over client-specific work. Where a general-purpose internal library is used, it is identified in the contract before it is used, never discovered afterwards.
Incidents
A named owner, written notification terms
Every supported system has a named engineer accountable for it. Notification windows and escalation paths are agreed in the contract rather than improvised during an incident, and a written post-incident record states what happened, why, and what changed as a result — including where the cause was VenSoc’s.
Personal data and GDPR
Where an engagement involves personal data, VenSoc acts as a processor and the client as controller. A data processing agreement is signed before processing begins, and standard contractual clauses cover transfers outside the EEA, since VenSoc is established in Pakistan — a country without a European adequacy decision. That is a material fact for a European client and is stated up front rather than buried.
Sub-processors depend on the infrastructure each client chooses, so they are listed in that engagement’s DPA rather than asserted generically here. Where a client requires prior approval of sub-processors, that goes into the agreement.
For this website specifically, the only personal data collected is what a visitor submits through the contact form. There is no analytics, no advertising pixel and no tracking cookie of any kind.
Reporting a vulnerability
If you believe you have found a security issue in a VenSoc-operated system or in this website, email the address below with enough detail to reproduce it. Reports are acknowledged, and we will tell you what we found and what we changed. Please do not run automated scanning against client production systems.
info@vensoc.comCommon questions
- Are you ISO 27001 or SOC 2 certified?
- No. VenSoc holds neither, and does not describe either as "in progress". Where a client requires certified suppliers, VenSoc is the wrong supplier and will say so at the first meeting. Specific controls can be committed contractually instead.
- Where is our data processed?
- In the infrastructure you choose. VenSoc does not require client data to be hosted on VenSoc infrastructure, and delivered systems run in the client’s own cloud accounts unless you asked otherwise. Engineering access happens from Pakistan, which is disclosed in the DPA and covered by standard contractual clauses.
- Do you copy production data to test with?
- No. Development and test environments run on synthetic or anonymised data. Where a defect can only be reproduced against real data, it is reproduced inside your environment under your controls.
- What happens to our access when the engagement ends?
- Revocation is a written step in the exit checklist, alongside handover of repositories, infrastructure definitions and documentation. It is your responsibility to confirm revocation on your side, and we will ask you to.