For your security team and procurement
Security controls, stated precisely enough to verify
This page is written for the people who will assess us, not for a brochure. It sets out our organisational and technical controls, how we handle your data, how our engineers access your environments, our compliance posture with certification and alignment clearly separated, and what we commit to on incident notification. Where a certification status is unresolved, it says so rather than implying otherwise.
- Certified, aligned and helps-you-achieve treated as three different claims
- Least-privilege, time-bound access to client environments, session logged
- Data residency options by market, subprocessors disclosed
- Incident notification within 24 hours of confirmation
Assessment summary
- Legal entity
- Redcubical Systems Private Limited
- Registered address
- Dev Heights, First Floor, Aman Vihar, Sahastradhara Road, Dehradun, Uttarakhand 248001, India
- Delivery locations
- Dehradun and Bengaluru, India
- Encryption at rest
- AES-256
- Encryption in transit
- TLS 1.3
- ISO 27001
- Aligned controls. Certification status: [confirm before publication]
- GDPR role
- Processor, with DPA and Standard Contractual Clauses
- DPDP Act 2023
- Processor for client data. Grievance officer published
- Questionnaire turnaround
- 3 to 5 business days
- Security contact
- nitesh@redcubical.com
Controls
Organisational security and technical controls
What controls do you actually operate
Organisationally: background verification before start, individually signed confidentiality and IP assignment, security awareness training with periodic refreshers, a documented joiner-mover-leaver process, least privilege by default, and a hard rule that production client data does not sit on an engineer's laptop. Technically: full-disk encryption, mobile device management, multi-factor authentication everywhere, hardware keys for privileged access, zero-trust network access and centralised logging.
Organisational security
- Background verification before an engineer starts: identity, address, education and employment history, conducted through a third-party verification provider. Additional checks where a client contract requires them, at the client's specification.
- Individual confidentiality and IP assignment. Every engineer signs their own agreement, not merely a company-level clause. Intellectual property assigns to the client on creation. Client-specific NDAs are executed by named individuals where required.
- Security awareness training at induction and refreshed at least annually, covering phishing, social engineering, secure coding, data classification and incident reporting. Simulated phishing exercises with results tracked as a metric rather than as a disciplinary matter.
- Joiner, mover, leaver process. Access is provisioned from a role definition rather than by copying a colleague. Role changes trigger an access review. Departures trigger revocation across identity, repositories, cloud accounts, communication tools and client systems, tracked to completion.
- Least privilege by default. New accounts start with no access to client environments. Access is requested, justified, approved and recorded, and reviewed quarterly with a documented removal of anything unused.
- No production client data on laptops. Development and testing use anonymised or synthetic datasets. Where production data must be examined, it is examined inside the client's environment through a logged session, not copied out.
- Clear-desk and visitor controls at both delivery locations, with access-controlled entry to engineering floors and visitor logging.
- Separation of duties on anything with financial or production impact, including a second reviewer on destructive infrastructure changes regardless of seniority.
Technical controls
- Full-disk encryption enforced on every endpoint, with the state verified by device management rather than trusted from a policy document.
- Mobile device management on all company endpoints: patch level enforcement, screen lock policy, remote wipe capability, USB mass storage restricted, and non-compliant devices blocked from company resources.
- Multi-factor authentication everywhere, with no exemptions for convenience. Legacy authentication protocols that bypass it are disabled at the identity provider.
- Hardware security keys for privileged access: cloud administrative roles, identity provider administration, production access and repository administration. Phishing-resistant factors specifically, because one-time codes are not.
- Zero-trust network access for internal and client system access, with device posture checked at connection time. Where a client mandates a traditional VPN we use theirs.
- Endpoint detection and response on all endpoints with centralised alerting, plus managed anti-malware.
- Centralised logging of authentication events, privileged actions, endpoint alerts and repository activity, retained for a defined period and reviewed on a schedule as well as on alert.
- Patch management with defined remediation windows: critical within seven days, high within thirty, tracked to closure with exceptions recorded and expiring.
- Email security with SPF, DKIM and DMARC enforcement on our sending domains, plus attachment and link protection inbound.
Secure SDLC
Security inside the development lifecycle
Gates in the pipeline rather than a review at the end. A security review that happens after the architecture is fixed can only produce a list of things that are now expensive.
How security enters the build
Six gates: threat modelling at design, mandatory peer review with no self-merge, static analysis and secret scanning on every commit, dependency and container scanning that blocks on fixable criticals, an SBOM generated and retained per build, and independent penetration testing before significant releases. Findings carry an owner, a severity and an expiry so exceptions cannot become permanent quietly.
-
Threat modelling at design time
For any new system or significant change we model trust boundaries, data flows and abuse cases before implementation, and record the result alongside the architecture decision. Authentication, authorisation and data classification decisions are made here, where they are still cheap.
-
Mandatory peer review
No self-merge to a protected branch, no exceptions for seniority. Reviewers check authorisation logic, input validation, error handling and data exposure specifically, not only correctness. Branch protection is enforced in the platform rather than requested in a policy.
-
Static analysis and secret scanning
Semgrep and CodeQL on every commit, tuned to reduce false positives so findings are read rather than ignored. gitleaks runs pre-commit and in the pipeline, and we scan full history on any repository we inherit, because a rotated secret in history is still a secret in history.
-
Dependency and container scanning
Trivy and Grype against dependencies and images, with Dependabot and Renovate raising upgrades continuously. Critical findings with a fix available block the build. Findings without a fix are recorded with a named owner and an expiry date rather than suppressed.
-
SBOM generation and retention
A software bill of materials in CycloneDX or SPDX format generated for every build and retained with the artefact. When the next widely exploited library vulnerability is published, the question "are we affected" is answerable in minutes rather than days.
-
Independent testing before significant release
Dynamic scanning with OWASP ZAP in the pipeline, and independent penetration testing coordinated with a third-party provider for major releases or on a client-mandated cadence. Findings are tracked to closure with retest evidence, not closed on assertion.
- Secrets never in source control. Cloud-native secret managers only, with rotation, and no environment files committed even to private repositories.
- Infrastructure policy as code. Checkov and Open Policy Agent evaluate every Terraform plan before apply, so a public bucket or an open security group fails review rather than production.
- Signed, immutable artefacts. One artefact promoted across environments, signed with cosign. Nothing is rebuilt per environment, because that means production runs bytes nobody tested.
- Least-privilege pipeline identities. Deployment roles are scoped per environment with short-lived credentials via OIDC federation, not long-lived access keys in a CI variable.
- Authorisation tested, not assumed. Automated tests assert that a user of one tenant cannot read another's data. Broken access control is the most common serious finding in the applications we inherit.
- Logging without leakage. Structured logs are reviewed for personal data and secrets. A stack trace containing a token is an incident, so we test for it.
Your data
Data classification, encryption, residency and subprocessors
How you handle our data
Every dataset is classified on entry, and the classification determines where it may live, who may access it and how long it is kept. AES-256 at rest, TLS 1.3 in transit, keys held in a managed key service with rotation and separated duties, retention defined per engagement, and verified secure disposal on exit. Residency options are set out by market below.
| Tier | Examples | Where it may be processed | Handling requirements |
|---|---|---|---|
| Restricted | Production personal data, protected health information, payment data, credentials, security findings | Client environment only, inside the client's own cloud tenancy | Named individuals only, hardware-key authenticated, session logged, never copied to an endpoint, never used for development or testing |
| Confidential | Source code, architecture documents, business logic, contracts, anonymised production extracts | Client repositories and our managed environments in agreed regions | Role-based access, MFA enforced, encrypted at rest and in transit, access reviewed quarterly |
| Internal | Delivery plans, estimates, sprint artefacts, internal runbooks | Our managed collaboration tooling | Company identity required, external sharing blocked by default and audited when granted |
| Public | Published documentation, marketing material, open-source contributions | Anywhere | Review before publication to confirm no client-identifying or confidential content is included |
Classification happens when data enters the engagement, not when someone asks about it later. If a dataset arrives unclassified, it is treated as Restricted until classified.
Encryption and key management
- At rest: AES-256 on databases, object storage, snapshots and backups. Encryption of backups specifically, because an unencrypted backup is the control people forget.
- In transit: TLS 1.3 with older protocol versions disabled rather than deprecated, and certificate lifecycle automated so expiry is not an incident source.
- Key management in the cloud provider's managed key service — AWS KMS, Azure Key Vault or Google Cloud KMS — with rotation enabled, key policies separated from data-plane roles, and key usage logged.
- Customer-managed keys supported where you want to hold the key material and retain the ability to revoke our access cryptographically.
- No application-layer secrets in configuration files. Secrets are resolved at runtime from a managed secret store with short-lived credentials.
Retention and disposal
- Retention defined per engagement in the contract, not left to default. We do not keep client data because it might be useful later.
- On engagement close we return or delete client data on your instruction, remove access, decommission environments we operated, and provide a written confirmation of what was deleted and when.
- Backups included. Deletion covers backup copies within the documented backup retention cycle, and we tell you what that cycle is rather than leaving it implicit.
- Media disposal by cryptographic erasure for cloud storage and certified destruction for physical media, with certificates retained.
Subprocessors and change notification
We use third-party services to deliver work, and pretending otherwise would fail the first serious vendor assessment. Our commitments:
- A current subprocessor list is maintained and provided as part of the data processing agreement, naming each subprocessor, the processing purpose and the processing location.
- Categories we use include cloud infrastructure providers, source control and CI platforms, communication and collaboration tooling, observability and error tracking, identity and device management, and background verification providers.
- Advance notification of change. We give at least 30 days' written notice before adding or replacing a subprocessor that processes your data.
- A right to object. If you reasonably object to a new subprocessor on data protection grounds, we will either find an alternative for your engagement or you may terminate the affected services without penalty. That is written into the DPA rather than offered informally.
- Due diligence on each one covering security posture, certifications, transfer mechanism and breach notification obligations, refreshed when the relationship materially changes.
- Client-mandated exclusions honoured. If your policy prohibits a specific provider, tell us at contracting and we will confirm in writing whether we can deliver without it.
| Your market | Primary data residency options | Where our engineers work from | Transfer mechanism |
|---|---|---|---|
| United Kingdom | UK regions (London) on AWS, Azure or Google Cloud | India, accessing your environment remotely | UK GDPR DPA with UK International Data Transfer Addendum, plus transfer impact assessment |
| European Union | EU regions including Frankfurt, Ireland, Amsterdam, Paris, Stockholm | India, accessing your environment remotely | EU GDPR Article 28 DPA with Standard Contractual Clauses, plus transfer impact assessment |
| United States and Canada | US and Canadian regions; HIPAA-eligible services where PHI is in scope | India, accessing your environment remotely | DPA with state-law addenda as applicable; BAA where PHI is processed |
| United Arab Emirates and Saudi Arabia | UAE and Saudi regions where available; in-country hosting where regulation requires it | India, with on-site presence arranged where a contract requires it | DPA aligned to applicable local data protection law and sector regulation |
| Singapore and Australia | Singapore and Sydney regions | India, accessing your environment remotely | DPA aligned to PDPA and Australian Privacy Principles respectively |
| India | Indian regions (Mumbai, Hyderabad) | India | DPDP Act 2023 processor terms. See DPDP compliance |
The honest position on residency: your data can stay in your region, but our engineers are in India and will access it from there. That is remote access, not a transfer of storage, and it is still a cross-border processing arrangement that your DPA and transfer impact assessment must cover. Any vendor with offshore delivery who implies otherwise is glossing over the point your own regulator will ask about. Where a contract genuinely requires processing only by personnel physically located in your jurisdiction, we will tell you we cannot meet that.
Access
How our engineers access your environments
What access will your team have
Through your identity provider, as named individuals, with least-privilege roles and no shared credentials. No standing write access to production. Elevation is time-bound, requires a recorded reason, and the session is logged. When an individual leaves your engagement, their access is removed within 24 hours, and we will provide the evidence.
| Control | How we operate it | Evidence available to you |
|---|---|---|
| Identity | Your identity provider, federated. We do not create local accounts in your systems and we do not want a separate credential store for your environment | Your own IdP logs, and a named-individual access roster we keep current |
| Named individuals only | Every account maps to one person. Shared or team accounts are refused, including where a client offers one for convenience | Access roster with role, environment, justification and grant date |
| Least privilege | Read-only by default. Write access scoped to the specific resources the role requires, defined in code rather than granted ad hoc | Role definitions in your infrastructure repository, reviewable in a pull request |
| Multi-factor and hardware keys | MFA on all access. Phishing-resistant hardware keys mandatory for any production or administrative role | IdP enforcement policy and per-user factor registration |
| No standing production write access | Production write is granted through time-bound elevation with a recorded reason and an automatic expiry, typically two to four hours | Elevation request log with requester, reason, approver, duration and expiry |
| Session logging | Privileged sessions logged, including commands executed where the access path supports it. Bastion or session-manager access rather than direct SSH with distributed keys | Session logs in your account, retained under your policy rather than ours |
| Change control | All changes through pull request with your reviewers included. No console changes to production infrastructure, and standing human write access removed to make that enforceable | Complete pull request and pipeline history in your repositories |
| Offboarding | Removal within 24 hours of an individual leaving the engagement, triggered by our leaver process and confirmed back to your team | Written offboarding confirmation naming the individual, the date and the systems revoked |
| Quarterly access review | A joint review of who holds what, with unused access removed rather than renewed by default | Signed-off access review record per quarter |
This model exists because it protects us as much as you. An engineer who cannot make an unreviewed production change also cannot be blamed for one, and a logged elevation is the difference between an incident investigation and an argument.
Compliance
Compliance posture, stated honestly
Three different claims, kept apart deliberately. "We are certified" means an accredited body has audited us and issued a certificate. "We are aligned with" means we implement the control framework without holding a certificate. "We help you achieve" means the obligation is yours and we build and evidence the controls for it.
Are you certified
We are aligned with the ISO 27001 control framework and can share the control mapping under NDA. We help clients achieve SOC 2, PCI DSS scope minimisation and HIPAA safeguards. We contractually commit as a GDPR processor and under the India DPDP Act 2023. Where formal certification status is unresolved, this page marks it as requiring confirmation rather than asserting it.
| Framework | The nature of our claim | What we actually do | Evidence we can provide |
|---|---|---|---|
| ISO/IEC 27001 | Aligned. Formal certification status: [confirm before publication] | An information security management system built to the ISO 27001 Annex A control set: risk assessment, asset and access management, cryptography, operations security, supplier management, incident management and continuity. Internal review on a defined cycle | Control mapping document, internal review summaries, policy set — under NDA. A certificate only if and when one exists |
| SOC 2 (Trust Services Criteria) | We help you achieve it. Whether Redcubical holds its own Type I or Type II report: [confirm before publication] | Implement and evidence the controls your auditor tests in the environments we build and operate: change management, logical access, monitoring, incident response, vendor management. Complete auditor evidence requests for our scope of the environment | Control narratives, change and access evidence, our completed sections of your auditor's request list |
| UK and EU GDPR | Contractual commitment as processor under Article 28 | Process only on your documented instructions and for the agreed purpose. Data processing agreement with Standard Contractual Clauses and the UK Addendum for transfers to India. Transfer impact assessment describing supplementary measures. Assist with data subject requests, records of processing and DPIAs | Signed DPA, SCCs, transfer impact assessment, subprocessor list, records of processing extract for your engagement |
| India DPDP Act 2023 | Contractual commitment as Data Processor for client data; Data Fiduciary for our own products and recruitment | Purpose limitation and processing on documented instruction, security safeguards, breach notification to the Data Fiduciary and to the Board as required, data-principal request handling, and a published grievance officer with a defined response window | Processor terms, breach notification procedure, and our DPDP compliance and grievance officer pages |
| HIPAA | Business associate agreement available. No HIPAA certification exists for any vendor, and we will not imply one | Execute a BAA where PHI is in scope. Apply the corresponding administrative, physical and technical safeguards: named-individual access, no PHI on endpoints, audit logging of all PHI access, encryption in transit and at rest, workforce training, and breach notification within the BAA timeframe | Executed BAA, safeguard mapping to the Security Rule, audit log configuration evidence |
| PCI DSS | We help you minimise scope. We are not a PCI-assessed service provider | Architect so cardholder data never touches your systems or ours: hosted payment fields, tokenisation, redirect flows. Where a system is genuinely in scope we implement the applicable requirements and support your qualified security assessor with evidence | Scope reduction architecture, network and data-flow diagrams, evidence packs for your assessor |
| Cyber Essentials and Cyber Essentials Plus | Aligned with the five technical control themes. UK certification status: [confirm before publication] | Boundary firewalls and internet gateways, secure configuration, access control, malware protection and patch management operated as described in the controls section above | Control evidence per theme. A certificate only if and when one exists |
If a procurement gate requires a certificate we do not hold, we will tell you at the first opportunity rather than at the end of a process. Losing a bid honestly is cheaper for both of us than being disqualified late over a claim that did not survive verification.
Commitments
Incident response, continuity, disclosure and getting your questionnaire answered
What do you commit to
On a confirmed incident affecting your data you are notified within 24 hours, with a named contact and updates on a fixed clock, and a written post-incident report within 10 business days. Security questionnaires are returned in 3 to 5 business days. Vulnerability reports go to our engagement contact and are acknowledged within 2 business days.
| Stage | Commitment | Notes |
|---|---|---|
| Detection and triage | Alerts routed to a named on-call engineer with a documented escalation path to a founder. Severity assigned against a published matrix | We do not operate a staffed 24-hour SOC. Alerting is automated and on-call is human |
| Initial client notification | Within 24 hours of confirming an incident affecting your data, whether or not the full extent is yet known | We notify on confirmation, not on completion of investigation. An early notification with unknowns is more useful to you than a late complete one |
| Regulatory support | Information and assistance sufficient for you to meet a 72-hour GDPR Article 33 notification, and DPDP Act notification to the Data Fiduciary and Board as required | You are the controller or Data Fiduciary. The regulatory clock is yours; our job is to make it possible to meet |
| Containment and communication | Containment before diagnosis. A named incident contact for you, and updates at fixed intervals even when there is nothing new to report | Silence during an incident is what turns a technical problem into a relationship problem |
| Post-incident report | Written report within 10 business days: timeline, contributing factors, data affected, actions taken and dated remediation commitments | Blameless in tone, specific in content. Actions have owners and dates or they are not actions |
| Remediation verification | Remediation items tracked to closure with evidence, and reported back to you rather than closed internally on assertion | You can ask for the status of any item until it is closed |
Business continuity and disaster recovery
- Two delivery locations, Dehradun and Bengaluru, so a single-site disruption does not stop an engagement. Team continuity plans name a secondary contact per engagement.
- Remote-capable by default. All work is performed against cloud environments through managed devices, so a site becoming unavailable is an inconvenience rather than an outage.
- Key-person risk addressed explicitly. No engagement depends on one individual holding undocumented knowledge. Architecture decision records and runbooks exist for this reason as much as for handover.
- For systems we operate on your behalf, recovery point and recovery time objectives are agreed in the contract, backups are tested by restore rather than assumed, and a failover exercise is rehearsed in a non-production environment before go-live.
- Availability target of 99.95% on supported architectures, expressed as an SLO with an error budget rather than as a marketing figure.
- Continuity plan review on a defined cycle, with the test outcome recorded. A plan that has never been exercised is a document, not a capability.
Responsible disclosure
If you have found a vulnerability in a Redcubical Systems system or product, we want to hear about it and we will not threaten you for telling us.
- Where to send it. nitesh@redcubical.com with "Security disclosure" in the subject line. Include enough detail to reproduce.
- Acknowledgement within 2 business days, with a named contact for the report.
- Assessment and a planned remediation date within 10 business days, communicated to you.
- What we ask. Give us reasonable time to fix it before publishing, do not access or modify data belonging to others, do not degrade service availability, and do not use social engineering against our staff.
- What we commit to. No legal action against researchers acting in good faith within those bounds, credit where you want it, and a straight answer if we decide not to fix something and why.
- We do not currently operate a paid bug bounty. Saying so is more useful than leaving you to discover it after the work.
Getting a security questionnaire completed
- Send it to nitesh@redcubical.com, addressed to Nitesh, Head of Global Engagement. It is routed to the person who owns the controls.
- 3 to 5 business days for a standard questionnaire: CAIQ, SIG Lite, VSA or your own template.
- Up to 10 business days for long-form questionnaires requiring evidence attachments or bespoke control narratives.
- We answer "no" where the answer is no, with the compensating control if one exists. A questionnaire returned with every box ticked should worry you.
- Portal-based assessments supported. Tell us the platform and we will complete it there rather than asking you to transcribe.
- Architecture and control walkthrough available as a call with the engineers who operate the controls, which is usually faster than three rounds of clarification by email.
Documents we can share under NDA
- Information security policy set and the ISO 27001 control mapping
- Data processing agreement template with Standard Contractual Clauses and the UK Addendum
- Current subprocessor list with processing purposes and locations
- Transfer impact assessment covering India as a processing location
- Business associate agreement template where PHI is in scope
- Incident response and breach notification procedure
- Business continuity and disaster recovery plan summary
- Background verification and joiner-mover-leaver process description
- Secure development lifecycle description and pipeline gate configuration
- Most recent independent penetration test summary for systems we operate, where the client concerned permits it
Also relevant: our privacy policy, DPDP Act compliance page and grievance officer details.
Answers
Security and compliance questions
Is Redcubical Systems ISO 27001 certified?
Our information security management system is built to align with the ISO 27001 control framework, and we can share our control mapping under NDA. Formal ISO 27001 certification status: [confirm before publication]. We will not describe alignment as certification, because a procurement team can verify a certificate and is entitled to be annoyed if the distinction was blurred.
Do you have a SOC 2 report?
We support clients pursuing SOC 2 by implementing and evidencing the controls their auditor will test, and we complete auditor evidence requests for the parts of the environment we operate. Whether Redcubical itself holds a SOC 2 Type I or Type II report: [confirm before publication]. If you need a vendor SOC 2 report as a hard procurement gate, ask us directly and we will give you a straight answer rather than a qualified one.
Will you sign a data processing agreement and can you support GDPR transfers?
Yes. We act as a processor under Article 28 of the UK and EU GDPR, sign a data processing agreement including the current Standard Contractual Clauses for transfers to India, and provide a transfer impact assessment covering the supplementary measures we apply. Our subprocessor list is disclosed and changes are notified in advance.
How do you comply with India's DPDP Act 2023?
We operate as a Data Processor for client data and as a Data Fiduciary for our own products and recruitment data. That means purpose-limited processing on documented instructions, consent and notice mechanisms in our products, data-principal access and erasure handling, breach notification workflows, and a published grievance officer. Details are on our DPDP compliance page and grievance officer page.
Can you sign a HIPAA business associate agreement?
Yes, where the engagement involves protected health information we will execute a business associate agreement and apply the corresponding safeguards: access restricted to named individuals, no PHI on endpoints, audit logging on all access, encryption in transit and at rest, and breach notification within the agreement's stated timeframe. We are not a HIPAA-certified entity, because no such certification exists.
How do your engineers access our production environment?
Through your identity provider, as named individuals, with least-privilege roles, multi-factor authentication and hardware keys for privileged access. No shared credentials, no standing production write access, time-bound elevation with a recorded reason, and session logging. Offboarding of any individual removes access within 24 hours of their leaving the engagement.
How long does it take you to complete a security questionnaire?
Three to five business days for a standard questionnaire such as a CAIQ, SIG Lite or a client's own template. Longer questionnaires requiring evidence attachments may take up to ten. Send it to our engagement contact and it goes to the person who owns the controls, not to a salesperson filling boxes.
What happens if you suffer a security incident affecting our data?
You are notified without undue delay and in any case within 24 hours of us confirming an incident affecting your data, whether or not we know the full extent yet. You receive a named incident contact, updates on a fixed clock, containment actions taken, and a written post-incident report within ten business days including what we are changing.
Send us your security questionnaire
Addressed to Nitesh, Head of Global Engagement. Standard questionnaires come back in three to five business days, answered by the people who operate the controls. We are happy to start with the questionnaire rather than a sales call.