Security and compliance, answered before you send the assessment.
Your security team is going to ask where data lives, who can reach it, how code gets reviewed and what happens during an incident. Those answers are on this page — including the section listing what we don't certify, which is the part most vendor pages leave out.
Canopus builds security into delivery rather than selling it separately. We deploy into your cloud account and region, use named time-limited engineer access, review every code change, scan dependencies and secrets in CI, and sign NDAs and GDPR-aligned data processing agreements. We are not ISO 27001 or SOC 2 certified, and we say so plainly.
What we don't claim
Put first, deliberately. Every one of these is something a supplier could imply without technically lying, and every one causes a wasted month when discovered at contract stage.
Certifications we don't hold
- ISO 27001 — not currently certified. We implement the technical controls; we don't hold the certificate.
- SOC 2 Type I or II — no report to share. We build the controls that let your product pass.
- PCI DSS Level 1 — we don't take card data into our own scope. We integrate Stripe, Adyen and equivalent providers so card data stays with them.
- HIPAA "compliant vendor" — compliance belongs to the covered entity. We deliver HIPAA-aware and sign a BAA where we process PHI.
Work we decline on regulatory grounds
- Medical device software under MDR or FDA classification, including anything that would require a notified body.
- Clinical decision support that makes diagnostic or treatment recommendations.
- Payment infrastructure where we would hold card data rather than tokenise through a provider.
- Anything requiring an approval we can't evidence as a precondition of the system being legal to operate.
Why publish this
Because the alternative is a page of reassuring language that survives until your security reviewer asks a direct question. A supplier that overstates its position costs you a procurement cycle and costs us a relationship. If a certification is a hard requirement for your vendors, tell us on the first call — we'll say straight away whether we can meet it, and if not, we'd rather you spend the month talking to someone who can.
Where your data lives and who can reach it
The default is that your data never leaves your own infrastructure.
Deployed into your cloud account and region
We build in your AWS, Azure or Google Cloud account rather than hosting you on ours. You own the billing relationship, the audit log and the ability to revoke our access in one action without asking us. Region is chosen for your residency requirements before any infrastructure is created.
Consequence: if our engagement ends tomorrow, nothing needs migrating and no data sits with us.
Individual accounts, least privilege, time-limited
No shared credentials, ever. Each engineer has a named account, scoped to the role they need, granted through your identity provider where you have one. Access is reviewed at each engagement milestone and revoked at exit with written confirmation of what was removed and when.
Consequence: your audit log names a person, not "the vendor".
Staging on anonymised data, production access approved
Staging environments are seeded with anonymised data of realistic shape, not a copy of production. Where production access is genuinely unavoidable — a live incident, a data migration — it's time-boxed, logged, and approved in advance by a named person on your side.
Consequence: most of our engineers never see a real customer record.
In a secret manager, rotatable without a redeploy
AWS Secrets Manager, Azure Key Vault or HashiCorp Vault — never in environment files on a server, never in the repository, never in a chat message. Rotation doesn't require a code change, which is what makes rotation actually happen after someone leaves.
Consequence: an engineer leaving is a credential rotation, not a risk assessment.
Security inside the development process
Controls that run on every change, rather than a review at the end that finds everything at once.
- Code review on every change, no self-mergesBranch protection enforces it — it isn't a convention people can skip under deadline.
- Dependency scanning in CIKnown vulnerabilities surface at merge, and findings are triaged rather than accumulated in a dashboard.
- Secret scanning before commitPre-commit hooks plus repository scanning, because the fastest leak is a key pasted into a config file.
- OWASP Top 10 handled at framework levelParameterised queries, output encoding, CSRF tokens, security headers — defaults, not per-feature decisions.
- Least-privilege service accountsEach service gets the permissions it needs and no more, defined in infrastructure code and reviewable.
- Audit logging of sensitive actionsWho accessed which record, who changed a permission, who exported data — retained per your policy.
- Change management through CIEvery production change traceable to a merged, reviewed pull request. This is also what auditors want to see.
- Third-party penetration testing arrangedWhere the system justifies it. We don't present our own review as equivalent to an independent test.
What we can build toward, and where the line is
We're engineers, not auditors. The split below is where that distinction bites.
| Framework | What we build | What stays with you |
|---|---|---|
| GDPR / UK GDPR | Lawful-basis-aware data models, consent capture, per-subject export and deletion, retention rules, regional hosting, processor agreements | Your privacy notice, records of processing, DPO appointment, lawful basis decisions |
| SOC 2 | RBAC, audit logging, encryption at rest and in transit, access reviews, change management through CI, backup and tested restore evidence | Policies, the audit relationship, evidence collection process, HR and vendor-management controls |
| ISO 27001 | The technical Annex A controls that are engineering work — access control, cryptography, logging, secure development, backup | ISMS scope, risk assessment, management review, internal audit and the certification body |
| HIPAA | HIPAA-aware delivery: access controls, encryption, audit trails on record access, minimum-necessary handling, BAA where we process PHI | Covered-entity obligations, workforce training, risk analysis, breach notification decisions |
| PCI DSS | Integration with Stripe, Adyen, Razorpay and equivalents so card data is tokenised and never enters your systems or ours | Your SAQ, and any scope you retain by handling card data outside the provider |
Scroll the table sideways to see both columns.
If something goes wrong
Named contacts on both sides are agreed at contract signature, not looked for during an incident. On confirming an incident affecting your systems or data we notify you without delay — we don't wait for a complete diagnosis before telling you something happened, because that delay is what turns an incident into a trust problem.
The sequence is contain, preserve, communicate, then investigate. You receive a written timeline and root-cause account afterwards, including what we got wrong. Where the incident triggers a regulatory notification obligation, that decision is yours as controller — we provide the facts you need to make it inside the deadline.
What security reviewers ask
Are you ISO 27001 or SOC 2 certified?
We're not currently certified, and we won't imply otherwise. What we do is build the technical controls those frameworks require into the systems we deliver — access control, audit logging, encryption, change management through CI, backup and restore evidence — so our clients can pass their own audits. If certification is a hard procurement requirement for your vendors, tell us early.
Do you sign NDAs and data processing agreements?
Yes, both, as standard. A mutual NDA is signed before discovery so it's in place before you send anything sensitive. Where we process personal data on your behalf we sign a GDPR-aligned DPA naming purposes, sub-processors, regions and retention.
Where is our data stored and who can access it?
In your own cloud account and chosen region wherever possible — we deploy into your infrastructure rather than hosting you on ours. Engineer access is named, role-scoped and time-limited, granted through your identity provider where you have one, and revoked at engagement end with written confirmation.
Do your engineers access production data?
Only where the work genuinely requires it, never as a default. Staging is seeded with anonymised data rather than a production copy. Where production access is unavoidable — a live incident, a data migration — it's time-boxed, logged and approved by a named person on your side.
What secure development practices do you follow?
Code review on every change with no self-merges, automated dependency and secret scanning in CI with findings triaged rather than only reported, parameterised queries and framework-level protections against the OWASP Top 10, secrets in a secret manager, and least-privilege service accounts. Where the system justifies it we arrange third-party penetration testing.
What happens if there's a security incident?
Named contacts on both sides are agreed at contract signature. We notify you without delay on confirming an incident affecting your systems or data, contain first, preserve logs, and provide a written timeline and root-cause account afterwards. We don't wait for a full diagnosis before telling you something happened.
Can you help us prepare for a client's security review?
Yes. Most of the technical controls in a SOC 2 or ISO 27001 questionnaire are engineering work: RBAC, audit trails, encryption, access reviews, change management, backup testing. We implement those and produce the evidence. Policy, governance and the audit relationship stay with you.
Which sub-processors do you use?
For our own operations: cloud hosting with AWS, Azure or Google Cloud depending on engagement, GitHub for source control, and standard business tooling for communication. Any sub-processor touching your data is named in the DPA, and we give notice before adding one.
Related pages
Send the questionnaire. We'll answer it properly.
If your security team has a standard vendor assessment, send it before the technical conversation. We'd rather find a blocker in week one than in week six — and if we can't meet a requirement, we'll say so directly.
- Email — [email protected]
- Phone / WhatsApp — +91 817 979 7732
- Mutual NDA first, before anything sensitive changes hands