Resources
Security and Compliance Resources: The Questions Clients Ask, Answered in Public
We are writing up the guidance our consultants give during engagements: framework explainers, testing notes and the checklists we work from. What is here are the answers we give most often, the topics the writing will cover, and a direct line if you need something sooner.
Answers
The Questions We Hear Most
These come up in nearly every scoping call. The answers are the same ones we give on the phone, in full, with no gate in front of them.
- We need ISO 27001 and SOC 2. Is that two separate projects?
- No, and running them separately is how most teams end up paying twice. The two frameworks overlap heavily, so we build one control set and one evidence base that satisfies both: the access reviews, the risk assessment, the vendor register, the incident process and the logging evidence are the same work described two ways. What differs is the output. ISO 27001 ends in a certificate from an accredited certification body after a Stage 1 and Stage 2 audit; SOC 2 ends in a report written by a licensed CPA firm, and SecureRoot is neither of those, so we prepare you for both and say plainly who signs what. The practical saving is your team's time rather than ours: your engineers answer a control question once, in one language, and the evidence is filed where both auditors can follow it. Where a deadline forces a choice, we sequence whichever one a customer or regulator is actually asking for.
- How long does DPDP Act readiness take?
- For most mid-size organisations, 90 to 120 days to a defensible position. That means personal data mapped to where it actually sits rather than where an architecture diagram says it should, consent and notice flows live in the product, a working route for data principal requests with someone accountable for answering them, retention that is written down and enforced, and a breach playbook you have rehearsed rather than filed. The range moves with how many systems hold personal data and how much of it sits with vendors, because third-party contracts are usually the slowest part. Readiness is not a certificate: the DPDP Act has no certifying body, so what you hold at the end is evidence you can show a customer, an investor or the Board. Maturity builds after that, which is why we usually stay on for the first few quarters rather than handing over a folder and leaving.
- How long does a VAPT take?
- Most web or API assessments run one to three weeks of testing, plus a retest window once your fixes are in. What moves it is scope rather than our calendar: the number of roles, features and endpoints for a web application, whether Android, iOS or both are in scope for a mobile app, and whether a network test is external, internal or both. You do not wait for the report to hear bad news. Critical findings reach you within three hours of discovery, so your team can start fixing while the rest of the test continues to its agreed end date. The testing is manual and exploit-driven, and every finding carries a proof of concept showing it was reproduced rather than inferred. The retest sits inside the engagement, so the closure evidence and the original report come from the same team and the same scope.
- Do you help with fixes, or only report problems?
- We help, and the engineer who found the flaw is the one who explains it to your developer. Every finding carries specific remediation guidance naming the component to change rather than a generic recommendation, and our engineers are available to yours during fix sprints, in your codebase and your language. When you tell us the fixes are in, we retest each finding and record whether it genuinely closed. A closed finding means fixed and retested, not acknowledged: if a fix does not hold, the finding stays open and we tell you why. That retest is part of the engagement rather than a separate invoice, and it produces a verified retest report you can hand to an auditor or a customer. What we do not do is change your code for you. The fix belongs to the team that owns the system, because they are the ones who will maintain it afterwards.
- What does an engagement cost?
- It depends on scope, and you get a fixed price in writing before any work starts. What moves the number is how many applications and environments are in scope, which frameworks are in play, and how much of the work sits with your team rather than ours. Indicative ranges are published on the service pages themselves, so you can size a budget before you speak to anyone, and the VAPT pages state what the band includes. The price is fixed after the scoping call, never before, and it does not grow later the way an open-ended estimate does. For testing, the retest is inside that price rather than billed separately. For compliance work, the certification body's or CPA firm's own fee is theirs and is quoted separately, because we do not issue certificates or reports and will not pretend that fee is ours to set.
- How do we start?
- One scoping call, usually 30 to 45 minutes, with the people who would do the work rather than an account manager. Bring whatever started this: a customer questionnaire, an auditor's finding, a regulator's deadline or a release you are nervous about. We ask what you run, who is asking you for what, and what has already been tried, then map the urgent against the important. You leave the call knowing what we would do first and why. What follows is a written scope, a timeline and a fixed price, usually within a couple of days, along with the rules of engagement for anything we would test. If we are not the right fit for the problem, we say so on the call and point you at who is, because a badly scoped engagement costs you more than a referral does. Nothing is chargeable until you accept that scope.
In Preparation
What We Will Publish, and What it Will Cover
Four series, drawn from work we have already delivered. The practice page behind each one carries the methodology, the tooling and the deliverables in detail.
- 01
Framework Explainers
What ISO 27001, SOC 2, PCI DSS and the DPDP Act actually require, written for the person who has to implement them rather than the person who signs the certificate.
Compliance Practice - 02
Testing Notes
How we test web applications, APIs, mobile apps and cloud environments, which classes of finding keep recurring, and what proof of exploitation should look like in a report.
VAPT Practice - 03
Remediation Guidance
The fix advice we hand engineering teams: configuration baselines, dependency upgrades, authorisation patterns and the retest evidence that closes a finding properly.
Hardening Practice - 04
Regulatory Updates
Changes to Indian and international rules that alter what your programme has to prove, and what they mean for the controls you already run.
DPDP Act Readiness
Need Something We Have Not Written Yet?
If you want the control mapping, the checklist or the test plan behind any answer on this page, ask for it. We will send what we have, and say so plainly when we do not have it yet.
We reply within one business day.