Services / Protect
Security engineering and compliance evidence that survives an audit
We do the technical work security programmes are made of: threat modelling, secure SDLC gates, penetration testing, cloud posture hardening, vulnerability management with real service levels, and evidence preparation for SOC 2, ISO 27001, HIPAA, GDPR, the India DPDP Act 2023 and PCI DSS. We are not a certification body and not a licensed auditor, and we are explicit about where our role ends.
- STRIDE threat models produced with your engineers, not delivered to them
- Vulnerability SLAs by CVSS severity, measured from triage
- Evidence collection automated so an audit is a query, not a scramble
- Explicit boundary: we prepare and remediate, we do not certify
At a glance
- Testing scopes
- Web, API, cloud configuration, network, mobile, social engineering
- Frameworks supported
- SOC 2, ISO 27001, HIPAA, GDPR, DPDP 2023, PCI DSS
- CI security tooling
- Semgrep, CodeQL, Trivy, OWASP ZAP, gitleaks, Checkov
- Cloud posture
- AWS Security Hub, GuardDuty, Config, Azure Defender, GCP SCC
- Critical remediation target
- 24 to 72 hours from confirmed triage
- GDPR breach notification
- 72 hours to the supervisory authority
- What we are not
- A certification body, a licensed auditor, or an insurer
- Enquiries
- nitesh@redcubical.com
Design
Threat modelling with STRIDE, walked through
The cheapest security work happens before code exists. A threat model is a structured argument about how your system could be abused, and it takes half a day per bounded context.
How STRIDE works
We draw a data flow diagram with your engineers, mark trust boundaries, then walk each element against six threat categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. Each identified threat gets a mitigation, an owner and a test. The output is a backlog, not a document.
-
Draw the data flow diagram
External entities, processes, data stores and data flows, with trust boundaries marked where data crosses from less trusted to more trusted. Drawn live with the engineers who built it, which regularly surfaces a flow nobody had documented.
-
Spoofing: can an attacker be someone else?
Authentication of users, services and devices. Session and token handling, service-to-service identity, webhook sender verification. Typical mitigations are multi-factor authentication, short-lived tokens with rotation, mutual TLS between services, and signature verification on inbound webhooks.
-
Tampering: can data or code be altered?
Integrity of data in transit and at rest, request parameters, client-supplied prices and quantities, and the build supply chain. Mitigations include server-side validation of everything, integrity checks, signed artefacts with an SBOM, and pinned dependency digests.
-
Repudiation: can an action be denied?
Audit logging of security-relevant events with sufficient identity, time and detail to reconstruct what happened. Append-only storage, tamper-evident retention, and clocks synchronised across systems so a timeline actually assembles.
-
Information disclosure: what can leak?
Excessive data in API responses, verbose error messages, identifiers that can be enumerated, personal data in logs and analytics, misconfigured storage, and cross-tenant leakage in a multi-tenant model. Mitigations are field-level authorisation, response shaping, log redaction, encryption with managed keys, and tenant isolation tested rather than assumed.
-
Denial of service: what can be exhausted?
Rate limits per identity and per endpoint, quotas, expensive query protection, request size caps, GraphQL query depth and cost limits, and back pressure. Also the neglected case: a single tenant consuming shared capacity and degrading everyone else.
-
Elevation of privilege: can a boundary be crossed?
Authorisation on every request, checked server-side against the resource rather than inferred from the interface. Object-level checks to prevent one customer reading another customer records. Least privilege on service roles. This category produces the most severe findings in almost every test we run.
-
Rank, mitigate, and convert to tests
Each threat is scored on likelihood and impact, assigned an owner and a target date, and where possible turned into an automated test. A threat model that does not produce test cases will be out of date within a quarter.
Build
Secure SDLC gates and the tooling behind them
Where security runs in the lifecycle
Security controls sit at the stage where they are cheapest. Design gets a threat model, commit gets secret scanning, pull request gets SAST and SCA, build gets image scanning and artefact signing, deploy gets infrastructure policy checks, and the running system gets DAST, posture monitoring and runtime detection.
| Stage | Control | Tooling | Blocking? | Typical duration |
|---|---|---|---|---|
| Design | STRIDE threat model, data classification, privacy impact assessment where personal data is involved | Workshop with a data flow diagram, threats recorded as backlog items | Gate on architecture sign-off for new contexts | Half a day per bounded context |
| Commit | Secret detection on the diff and on history | gitleaks, TruffleHog, provider-side push protection | Yes, and triggers a rotation procedure because a committed secret is compromised | Under 30 seconds |
| Pull request | Static analysis on changed files, dependency and licence checks, infrastructure as code policy | Semgrep or CodeQL, Trivy or Dependabot, Checkov or tfsec | Yes on new critical and high findings with an available fix | 2 to 5 minutes |
| Build | Container image scan, base image policy, artefact signing, SBOM generation | Trivy or Grype, cosign, Syft | Yes on fixable criticals. Unsigned artefacts never promote | 1 to 3 minutes |
| Pre-deploy | Infrastructure plan policy evaluation, drift detection, privileged change review | OPA or Checkov against the Terraform plan, with a second reviewer on stateful destroys | Yes on policy violation | Under 2 minutes |
| Runtime | Cloud posture monitoring, threat detection, anomaly alerting, audit log integrity | AWS Security Hub, GuardDuty and Config, Azure Defender for Cloud, Google Security Command Centre | Continuous, alerting rather than blocking | Ongoing |
Only gates that finish fast and produce actionable messages survive. A SAST run taking twenty minutes on a full codebase gets disabled within a month. We scope static analysis to changed files, tune rules to remove the noise that trains people to ignore output, and put the expensive full scans on a nightly schedule.
| Category | What it finds | Tools we use | Blind spots |
|---|---|---|---|
| SAST (static application security testing) | Injection patterns, unsafe deserialisation, hardcoded credentials, weak cryptography, framework misuse | Semgrep for fast custom rules, CodeQL for deeper data flow analysis, SonarQube where an estate already runs it | Cannot see runtime configuration or business logic flaws. Produces false positives that must be tuned or the output gets ignored entirely |
| DAST (dynamic application security testing) | Reflected and stored injection, authentication and session weaknesses, missing security headers, exposed endpoints, verbose errors | OWASP ZAP in CI, Burp Suite for manual and authenticated deep testing | Needs a running, authenticated environment. Coverage is limited to what it can reach and crawl. Poor at multi-step business logic |
| SCA (software composition analysis) | Known vulnerabilities in direct and transitive dependencies, container base image CVEs, licence policy violations | Trivy, Grype, Dependabot, Renovate for automated upgrade pull requests | Reports vulnerable versions present, not whether the vulnerable code path is reachable. Expect a high volume of findings that are not exploitable in your context |
| Secret scanning | API keys, tokens, private keys and credentials in code, history, configuration and container layers | gitleaks, TruffleHog, platform-native push protection | Cannot detect a secret that has been encoded or split. Detection is not remediation: the secret must be rotated, not merely deleted |
| IaC and posture scanning | Public storage buckets, permissive security groups, unencrypted volumes, missing logging, over-broad IAM policies | Checkov, tfsec, AWS Config with conformance packs, Security Hub standards | Checks configuration, not intent. A resource can be compliant with every rule and still be wrong for your threat model |
Tooling is the easy half. The half that determines outcomes is triage discipline: every finding accepted, fixed or suppressed with a reason, an owner and an expiry. A dashboard with several hundred unreviewed findings gives you no security benefit and gives an auditor a documented failure of your own vulnerability management process.
Test
Penetration testing: scope, report, retest, price
What a penetration test is
A penetration test is a human attempting to compromise a defined scope within agreed rules of engagement. It finds what scanners cannot: chained business logic abuse, broken access control between tenants, privilege escalation and lateral movement. Scope, authorisation, timing and escalation contacts are agreed in writing before any traffic is sent.
| Scope | What is tested | Typical effort | Indicative price (USD) | Prerequisites |
|---|---|---|---|---|
| Web application | Authentication and session management, authorisation and object-level access control, injection, business logic abuse, file handling, multi-tenancy isolation, client-side issues | 5 to 10 tester-days | 4,000 to 8,000 | A stable staging environment with production-like data, one account per role, and written authorisation from the system owner |
| API | Authentication and token handling, object and function level authorisation, mass assignment, rate limiting, input validation, resource consumption, schema-driven fuzzing | 3 to 7 tester-days | 3,000 to 6,000 | OpenAPI or Postman collection, credentials per role, and a non-production environment with representative data volumes |
| Cloud configuration review | IAM policy analysis and privilege escalation paths, network exposure, storage and database access, encryption and key management, logging coverage, guardrail effectiveness | 4 to 8 days | 4,000 to 9,000 | Read-only audit role across accounts and an architecture diagram |
| External network | Perimeter service discovery, exposed management interfaces, TLS and certificate configuration, patch currency, default and weak credentials | 3 to 6 days | 3,000 to 7,000 | IP ranges and domains in scope, written authorisation, and a maintenance window if intrusive testing is agreed |
| Mobile application | Local data storage, keychain and keystore usage, certificate pinning bypass, tamper and root detection strength, deep link handling, and the backend API behind the app | 5 to 9 days per platform | 5,000 to 10,000 per platform | A test build, test accounts, and acceptance that client-side controls will be bypassed as part of the test |
| Social engineering and phishing simulation | Simulated phishing campaign, pretext telephone calls where agreed, and physical access attempts if contracted | 3 to 8 days | 3,000 to 8,000 | Written authorisation from a named executive sponsor, HR and legal sign-off, and an agreed policy on how individual results are handled |
Prices are indicative for scoping conversations and move with authenticated role count, endpoint count, environment complexity and reporting requirements. Regulated-scope testing with formal evidence requirements sits above these ranges. We will not quote a penetration test without scoping it, because a fixed price offered blind is almost always an automated scan with a report template on top.
What a real report contains
- Executive summary in business language: what an attacker could achieve, what data was reachable, and the three things to fix first. Readable by a board, and no more than two pages.
- Scope and rules of engagement stating exactly what was and was not tested, the test window, and any constraint that limited coverage.
- Findings with reproduction steps that a developer can follow: exact request, payload, preconditions, and the observed result. A finding nobody can reproduce will not be fixed.
- Severity with justification. CVSS vector plus a written contextual rating, because a CVSS 7.5 on an internal admin tool and on your public login page are not the same risk.
- Specific remediation advice. Not "validate input" but the change, at the layer, in your framework.
- Attack narrative for chained findings, showing how three medium issues combined into a critical outcome. This is what distinguishes a test from a scan.
Retest policy and cadence
- Retest included for critical and high findings within 90 days of the original report, at no additional cost, with an updated report reflecting closure.
- Closure requires evidence. A finding is closed when the original attack path fails on retest, not when a ticket is marked done.
- Annual full test minimum, plus a test after any significant architectural change, new authentication mechanism, or new class of data entering the system.
- An honest limitation. A clean report means the tester found nothing exploitable within the agreed scope, time and skill applied. It is evidence of diligence, not proof of security, and we will not let it be represented as more than that.
Operate
Cloud posture, identity, secrets and vulnerability management
Cloud security posture
Most cloud breaches are misconfiguration and over-privileged identity, not exotic exploits. We put preventative guardrails in place first so the mistake cannot be made, then detective controls for what slips through, then a vulnerability management process with service levels by severity so findings actually close.
Preventative guardrails
- Service control policies at the organisation level that make the dangerous action impossible: no public bucket ACLs, no disabling CloudTrail, no unencrypted volume creation, no resource creation outside approved regions.
- Block public access enforced at account level on object storage, not per bucket. Per-bucket settings get changed by someone in a hurry.
- IMDSv2 required on every instance. Version 1 of the instance metadata service is how a server-side request forgery becomes credential theft, and requiring version 2 closes that path.
- Least privilege by construction. Roles scoped to specific actions on specific resources, with permission boundaries and no wildcard administrator role attached to workloads.
- No long-lived access keys. Federated human access with short-lived credentials, and OIDC-based workload identity for pipelines instead of stored keys.
- Guardrails as code. Every control expressed in Terraform and policy-as-code, so it is reviewable, versioned and reproducible across accounts.
Identity and secrets
- Single identity provider with SSO and enforced multi-factor authentication, phishing-resistant where the risk justifies it. One place to disable an account on the day someone leaves.
- Just-in-time privileged access. No standing production write access for humans. Time-bound elevation with a stated reason, an approver and a full audit record.
- Quarterly access reviews with evidence retained. This is both a genuinely useful control and one of the most commonly failed audit items.
- Secrets in a managed store. AWS Secrets Manager, Azure Key Vault or HashiCorp Vault, retrieved at runtime by workload identity. Never in environment files in a repository, never in a container image, never in a CI variable that a build log can echo.
- Automated rotation for database credentials and API keys, with the application able to handle a rotation without a restart.
| Severity | CVSS range | Remediation target | Interim control if a fix is unavailable | Escalation |
|---|---|---|---|---|
| Critical | 9.0 to 10.0, or any severity with confirmed active exploitation | 24 to 72 hours from confirmed triage | Virtual patching at the WAF, disable the affected feature, network-isolate the component, or take the service offline if data exposure is ongoing | Immediate notification to the accountable executive, treated as an incident with a commander |
| High | 7.0 to 8.9 | 14 days | Compensating control documented, with monitoring specifically for exploitation attempts against that path | Weekly review until closed. Overdue items escalate to the engineering lead |
| Medium | 4.0 to 6.9 | 30 to 60 days, aligned to the release cycle | Risk acceptance with a named owner and an expiry date, never an indefinite acceptance | Monthly security review |
| Low | 0.1 to 3.9 | Next planned release cycle, or accepted with a documented rationale | Not usually required | Quarterly review |
Two adjustments to raw CVSS. First, exposure: an internet-facing system handling personal or payment data moves up a band, an internal tool behind SSO with no sensitive data may move down. Second, exploitability: a published proof of concept or inclusion in a known-exploited catalogue overrides the base score entirely. The clock starts at confirmed triage rather than at discovery, and triage itself has a target of one business day.
Compliance
Frameworks: what each requires, and exactly what we can do
What we can and cannot do
We do the engineering and evidence work: gap assessment, control implementation, automated evidence collection, policy drafting, remediation and audit support. We are not a certification body, not a licensed CPA firm, and not your auditor. Attestation and certification come only from an accredited independent body, and that separation exists for good reason.
| Framework | What it actually requires | Typical timeline | What we do | What we cannot do |
|---|---|---|---|---|
| SOC 2 Type I | An independent CPA opinion that controls are suitably designed at a point in time, across the trust services criteria you select. Security is mandatory; availability, confidentiality, processing integrity and privacy are optional | 3 to 5 months from a standing start to audit-ready | Gap assessment against the criteria, control implementation, policy set, automated evidence pipelines, readiness assessment, and support through fieldwork | Issue the report. Only a licensed CPA firm can. We also cannot audit controls we built, which would be a conflict of interest |
| SOC 2 Type II | The same criteria examined for operating effectiveness over an observation window, commonly 3 to 12 months. Evidence must show controls ran consistently throughout, not that they existed | Type I readiness plus the observation window plus 4 to 8 weeks of fieldwork | Evidence automation so access reviews, change approvals, vulnerability scans and training records are collected continuously rather than reconstructed later | Shorten the observation window, or produce evidence for a period during which the control was not running |
| ISO 27001:2022 | A management system, not a checklist. Scope and context, risk assessment methodology, a risk treatment plan, a Statement of Applicability across the Annex A controls, internal audit, management review, and continual improvement | 6 to 9 months to certification, via a Stage 1 documentation review and a Stage 2 implementation audit | ISMS documentation, risk assessment and treatment planning, Statement of Applicability, control implementation, internal audit preparation, and support during both stages | Certify you. That requires an accredited certification body. We also cannot act as your independent internal auditor for controls we implemented |
| HIPAA (US) | Administrative, physical and technical safeguards under the Security Rule, Privacy Rule obligations, a documented risk analysis, workforce training, business associate agreements, and breach notification within 60 days | 3 to 6 months for technical safeguard readiness | Technical safeguards: encryption, access control, audit controls, integrity, transmission security. Risk analysis support, and engineering evidence for your documentation | Act as your privacy officer, sign a BAA as if we were the covered entity, or provide legal interpretation of the Privacy Rule |
| GDPR (EU and UK) | Lawful basis for processing, records of processing activities, data protection impact assessments for high-risk processing, data subject rights within one month, privacy by design and default, processor agreements, transfer mechanisms, and 72-hour breach notification | 2 to 4 months for technical and engineering measures | Data mapping, technical measures for the rights machinery including export and erasure, retention automation, consent and preference infrastructure, transfer architecture, and breach detection and reporting capability | Serve as your Data Protection Officer, provide legal advice on lawful basis, or represent you before a supervisory authority |
| India DPDP Act 2023 | Consent and notice requirements, purpose limitation, data principal rights including correction and erasure, reasonable security safeguards, breach notification to the Data Protection Board and to affected principals, consent manager integration where applicable, and additional obligations if designated a significant data fiduciary | 2 to 4 months for technical readiness, subject to ongoing rules | Consent architecture and audit trail, purpose-tagged data inventory, rights fulfilment workflows, retention and deletion automation, security safeguards, and breach notification tooling | Act as your Data Protection Officer or grievance officer, or give legal opinion on the Act and its rules as they evolve |
| PCI DSS v4.0 — SAQ A | Card-not-present merchants who fully outsource payment pages to a validated provider with no card data touching their systems. Around 30 requirements, mostly policy, plus scanning of the redirect page | 4 to 8 weeks | Confirm the integration genuinely qualifies, implement the technical requirements, and prepare the self-assessment evidence | Sign the Attestation of Compliance on your behalf, or act as a Qualified Security Assessor |
| PCI DSS v4.0 — SAQ A-EP | Merchant websites that do not receive card data but can affect the security of the payment page, typically a JavaScript-based integration. Substantially broader than SAQ A, including scanning, script integrity monitoring and change control | 2 to 4 months | Segmentation and scope reduction advice, script integrity controls, quarterly scanning arrangement, and evidence preparation | Perform the ASV scan as an approved scanning vendor, or issue the attestation |
| PCI DSS v4.0 — SAQ D | Merchants or service providers that store, process or transmit cardholder data. All twelve requirement groups, roughly 250 to 350 controls depending on applicability, segmentation testing, and annual penetration testing | 6 to 12 months, and often best avoided | Scope reduction is our first recommendation, because moving to a hosted or tokenised integration can take you from SAQ D to SAQ A. Where SAQ D is unavoidable, control implementation and evidence | Act as a QSA, perform the ASV scan, or issue the Report on Compliance |
The pattern across all of these: the technical controls are the tractable part. What audits actually fail on is operational consistency, an access review skipped for a quarter, a change deployed without approval, training records missing for three joiners. We automate evidence collection precisely because manually assembled evidence is where the gaps appear.
Honest answer
Incident response, notification clocks, and why nobody can promise you will not be breached
Breach notification timelines
Notification clocks start when you become aware, not when you finish investigating. GDPR gives 72 hours to notify the supervisory authority. CERT-In directions require reporting specified incidents within six hours. HIPAA allows 60 days for individual notice. Those clocks run concurrently, so the decision tree must exist beforehand.
| Regime | Trigger | Deadline | Notify whom | Practical implication |
|---|---|---|---|---|
| GDPR Article 33 and 34 | A personal data breach likely to result in a risk to individuals | 72 hours to the authority from becoming aware. Individuals without undue delay where risk is high | The lead supervisory authority, and affected data subjects where high risk | A phased notification is permitted. You are expected to notify with what you know rather than wait for a complete picture |
| India DPDP Act 2023 | A personal data breach | As prescribed under the Act and its rules, without a graduated risk threshold in the primary text | The Data Protection Board of India and each affected data principal | Broader than GDPR in that there is no low-risk exemption in the statute, so a defensible assessment record matters |
| CERT-In directions (India) | Specified cyber incident types including unauthorised access, data breach and ransomware | 6 hours from noticing or being brought to notice | The Indian Computer Emergency Response Team | The tightest clock in practice. It requires a pre-agreed reporting path and a template ready to go |
| HIPAA Breach Notification Rule | Unsecured protected health information breach | 60 days to individuals. Annual for breaches under 500 individuals, 60 days for larger | Affected individuals, the Department of Health and Human Services, and media where 500 or more in a state | Encryption to the standard removes the notification obligation entirely, which is the strongest practical argument for it |
| Contractual obligations | As defined in your customer agreements | Frequently 24 to 48 hours, and often stricter than regulation | Affected customers, per contract | Usually the binding constraint in practice. Enterprise customers commonly negotiate notification windows tighter than any statute |
The single most useful preparation is a written decision tree answering: who declares an incident, who determines whether personal data is involved, who has authority to notify, and who speaks to customers. Without those four answers agreed in advance, the 72-hour clock is consumed by internal escalation rather than by assessment.
The response plan we implement
- Detect and triage. Alert reaches on-call with a runbook. Initial severity assigned within 30 minutes against a published matrix.
- Declare and assemble. A named incident commander, a scribe, and a communications owner who are not the people investigating. For a suspected data breach, legal and the privacy lead join immediately.
- Contain before eradicating. Revoke credentials, isolate the affected component, block the attack path. Preserve evidence before rebuilding anything, because a rebuilt server has destroyed the forensic record.
- Assess data impact in parallel. What categories of data, how many individuals, which jurisdictions. This determines the notification clocks, so it starts immediately rather than after containment.
- Notify on the clock. Regulator, customers, individuals, insurers and card schemes as applicable, using pre-drafted templates reviewed by legal in advance.
- Post-incident review within five working days. Blameless, written, with a timeline, contributing factors and dated actions with owners.
- Rehearse twice a year. A tabletop exercise including the notification decision, because the technical response is usually better prepared than the legal and communications response.
Security questionnaire and due diligence support
- A maintained answer library covering the questions that recur across SIG Lite, CAIQ, vendor-specific forms and enterprise procurement templates, each answer tied to the evidence that supports it.
- Evidence kept current. Architecture diagrams, data flow diagrams, penetration test summaries, policy documents, subprocessor lists and insurance certificates, versioned rather than rewritten each time.
- Accurate answers, including the negative ones. Where a control is not in place we say so and attach the plan and date. Overstating a control is a contractual misrepresentation discovered at the worst possible moment.
- Turnaround. Typically 3 to 5 working days for a standard questionnaire once the library is established, against the two to three weeks it commonly takes without one.
Answers
Cybersecurity and compliance questions
Can you certify us to SOC 2 or ISO 27001?
No. Certification and attestation can only be issued by an accredited certification body or a licensed CPA firm, and we are neither. What we do is the engineering and evidence work that determines whether an audit succeeds: gap assessment against the control set, control implementation, automated evidence collection, policy documentation, remediation of findings, and support during fieldwork. Any firm claiming it can certify you and also build your systems is describing a conflict of interest.
What does a penetration test actually cost?
Indicatively, a focused web application test runs 4 to 8 thousand US dollars for 5 to 10 tester-days, an API test 3 to 6 thousand, a cloud configuration review 4 to 9 thousand, an external network test 3 to 7 thousand, and a mobile application test 5 to 10 thousand per platform. Prices scale with authenticated role count, endpoint count and environment complexity. Anyone quoting a fixed price before scoping is either guessing or selling an automated scan with a report template.
How is a penetration test different from a vulnerability scan?
A scan is automated pattern matching against known signatures and misconfigurations. It is cheap, should run continuously, and finds known problems. A penetration test is a human attempting to chain findings into a real compromise: abusing business logic, escalating between tenants, moving laterally, and reaching data they should not. Scanners do not find broken access control between two customer accounts. Testers do. You need both, and a scan report presented as a penetration test is the most common thing we see mis-sold.
What are the vulnerability remediation SLAs you work to?
Measured from confirmed triage, not from discovery. Critical, CVSS 9.0 and above, or any actively exploited issue: 24 to 72 hours. High, 7.0 to 8.9: 14 days. Medium, 4.0 to 6.9: 30 to 60 days. Low, below 4.0: next planned release cycle. Internet-facing systems handling personal or payment data compress those windows. CVSS is a starting point and is adjusted for exploitability and your actual exposure.
How long does SOC 2 or ISO 27001 readiness take?
From a standing start, expect three to five months to be audit-ready for SOC 2 Type I, then a further three to twelve month observation window before a Type II report. ISO 27001 typically runs six to nine months to certification, including a Stage 1 documentation review and a Stage 2 implementation audit. The variable that dominates is not tooling, it is whether your organisation actually operates the controls consistently, because a Type II examines evidence over a period rather than at a point in time.
What are our breach notification obligations?
Under GDPR, notify the supervisory authority within 72 hours of becoming aware of a personal data breach where risk to individuals is likely, and notify affected individuals without undue delay where risk is high. Under the India DPDP Act 2023, notify the Data Protection Board and each affected data principal, with the Act framing notification without a graduated risk threshold. Sector rules add more: CERT-In directions require reporting specified incidents within six hours. HIPAA requires individual notice within 60 days. These run concurrently, which is why the decision tree must exist before an incident.
Can you guarantee we will not be breached?
No, and nobody honestly can. Security reduces the probability of compromise, reduces the damage when it happens, and shortens detection and recovery time. A well-run programme makes you a harder target than the alternatives and means an incident is contained rather than catastrophic. Any supplier offering a guarantee against breach is either misrepresenting what is achievable or relying on contract language you would not want to test.
We have a customer security questionnaire due. Can you help?
Yes, and this is one of the most common reasons clients come to us. We maintain your answers against the questions that recur across SIG Lite, CAIQ, vendor-specific forms and enterprise procurement templates, keep supporting evidence current, and answer the technical sections accurately. Where an answer is genuinely no, we say no and attach the remediation plan and date. Overstating a control in a questionnaire is a contractual misrepresentation, and it is discovered exactly when it matters most.
Start with a three-week security and compliance assessment
Fixed fee. You get a threat model for your primary context, a cloud posture review with prioritised findings, a secure SDLC gap analysis, a gap assessment against your target framework, and a costed remediation roadmap with severity-based timelines. The output is yours whether or not you engage us for the work.