Ankit Jangir Case study

ISO 27001 ISMS, built from zero

Authored and maintained · in production use

A policy nobody can evidence is not a control. It is a paragraph.

34 policies 16 registers SOC 2 / 3 VAPT to closure DPDP

Outcome

Platforms that clear a bank's vendor security review

Enterprise buyers — banks, insurers, large conglomerates — do not take a vendor's word that a platform is secure. They send a questionnaire with a few hundred controls, ask for evidence against each, and hand the answers to an assessor whose job is to find the gap.

Our products go through that process and come out the other side. Multiple assessments cleared, including a Big-Four independent review. Not because we answered well, but because the evidence existed before anyone asked for it.

I wrote the programme that makes that true, I keep it current, and I am the person in the room when the assessor has follow-up questions.

The questionnaire is the easy part. Having the evidence already is the work.

Structure

Policy → control → register → evidence

Every policy terminates in something an outsider can inspect. That chain is the whole design.

Policy 34 NUMBERED the commitment Control WHAT WE DO the mechanism Register 16 OPERATIONAL the record Evidence INSPECTABLE the artifact Assessment EXTERNAL the verdict EVERY POLICY TERMINATES IN SOMETHING AN OUTSIDER CAN INSPECT WORKED EXAMPLE Access control policy Quarterly recertification Recertification register Signed-off review Secure development SAST / SCA release gate Findings tracker Scan + SBOM output Business continuity DR drill, executed Drill register Execution report Where a control is not met: recorded in the exception register with rationale and review date — never a silent gap.
The register is the load-bearing element. A policy without one drifts toward the aspirational; a policy with one is falsifiable by anybody who opens the file.
34 policies
The commitments

Access control, incident response, secure development, third-party risk, cloud security, privileged access, endpoint, data classification, retention, localization, HR and physical security.

16 registers
The proof

Asset inventory, incident log, change and patch records, access recertification, RBAC matrix, backup completion, DR-drill reports, VAPT findings tracker, policy exceptions.

Technical evidence
The artifacts

CycloneDX SBOM per application, SAST and SCA gate results, pen-test reports with action-taken responses and revalidation, console screenshots of cloud controls.

Runbook
The repeatability

An evidence-capture procedure and index, so the next assessment is a retrieval exercise rather than a fortnight of scrambling.

Decisions & trade-offs

Registers before prose

The instinct when starting an ISMS is to write the policies first, because that is what the standard lists. I built the registers alongside them instead, and it changed what the policies could say.

A policy written without its register drifts toward the aspirational — "access is reviewed periodically." Reviewed by whom, how often, recorded where? If a register has to exist and be populated, the policy is forced into something falsifiable, because someone will eventually open the spreadsheet and check.

  1. 1Numbered, not narrative. Every policy carries an identifier so a questionnaire answer can cite one rather than attaching a forty-page document and hoping.
  2. 2Exceptions are a register, not a silence. Where we do not meet a control, that is recorded with a rationale and a review date. Assessors trust a documented exception far more than an unexplained gap they discover themselves.
  3. 3Findings tracked to revalidation. A pen-test report is not closed at remediation — it closes when the assessor retests and confirms. The tracker holds both rounds.
  4. 4Retention written as executable queries. A deletion policy that cannot be run is a promise. Ours ships with the statements that enact it.
The part that transfers

This is the same instinct that shows up in the security tooling: make the claim reproducible by someone who does not trust you. A control with a register behind it and a scanner finding that is identical between runs are the same idea applied to different problems.

Adjacent work

The programme in operation

Alongside authoring, the running of it: coordinating VAPT cycles with external assessors and driving findings through action-taken reports to full revalidation; embedding SAST and SCA as blocking release gates so a build cannot ship past an unresolved finding; PII assessment and field-level encryption; joiner-mover-leaver process with periodic access recertification; disaster-recovery drills executed and formally reported.

And the commercial end of it — completing the security questionnaires that decide whether an enterprise deal proceeds, mapping each control to the evidence that satisfies it.

What I’d do differently

Evidence capture should have been automated first

For the first assessments, gathering evidence was manual — console screenshots, exported logs, spreadsheets assembled by hand under time pressure. It worked, and it did not scale. The runbook and evidence index came later, and they should have come first.

That gap is a large part of why I later built tooling to collect posture evidence continuously. The best moment to capture proof that a control is working is while it is working, not three days before an assessor's deadline.