Governance, Risk and Compliance (GRC) is not a document folder — it is the operating system connecting what leadership decides, what the business is actually exposed to, and what auditors and regulators can verify. For a 50-500 person Indian company, the minimum viable GRC function has four parts: a written risk appetite, a living risk register, one control set mapped to every framework you must satisfy (ISO 27001, SOC 2, DPDP Act 2023, CERT-In directions, and RBI/SEBI rules where applicable), and continuous evidence collection instead of a pre-audit scramble.
Most Indian mid-market firms treat GRC as a chore that appears once a year before an ISO surveillance audit or a customer security questionnaire. That is how GRC becomes spreadsheet theatre — a risk register nobody opens between audits, a policy PDF nobody reads, controls that exist on paper but not in production. This guide covers what GRC actually means, the minimum viable operating model, how to run a risk register people use, and how to map one control set to multiple frameworks without duplicating work four times over.
What GRC actually means beyond the acronym
Each word does different work.
Governance is who decides. It is the risk appetite statement, the policy set, the named owners, and the reporting cadence to leadership or the board. Without governance, teams fix whatever is loudest that week instead of what the business actually decided matters.
Risk is what could go wrong and how much it matters. A risk register is not a list of vulnerabilities; a vulnerability is a technical finding, a risk is the business consequence of that finding being exploited, weighted by likelihood and impact. Conflating the two is the single most common reason risk registers stop being used — they turn into un-triaged dumps nobody can prioritize.
Compliance is proving, to a named external party, that governance and risk management actually happened. ISO 27001 certification, a SOC 2 report, a DPDP audit trail — these are evidence artifacts a specific framework accepts as proof. Compliance without governance and risk underneath it is spreadsheet theatre: paperwork satisfying a checklist without reducing the chance of an incident.
The minimum viable GRC operating model for 50-500 people
You do not need a five-person GRC department at this size. You need one accountable owner (often a CTO, Head of Engineering, or a compliance lead reporting into the CTO/CEO) and a small set of recurring rituals.
- A one-page risk appetite statement, approved by whoever owns the P&L — what level of risk is acceptable in which areas (customer data, uptime, financial systems, vendor access), signed off, revisited annually.
- An asset and data inventory — what systems exist, what data they hold, who owns them. Nothing else in GRC works without this.
- A single risk register, reviewed monthly by the accountable owner, quarterly by leadership.
- One control set mapped to every framework the business needs — not four separate control lists per certification.
- Continuous evidence collection — logs, screenshots, ticket trails, and config exports captured as controls run, not reconstructed before an audit.
- A quarterly reporting cadence to leadership — top risks, control status, open findings, trend versus last quarter.
The loop closes at the risk register, not the audit report. That distinction separates a working GRC function from a paperwork exercise — the audit is a checkpoint inside the loop, not the finish line.
Running a risk register people actually use
Risk registers fail for predictable reasons: too many rows, no clear owner per row, scoring nobody trusts, and no consequence when a risk sits open past its due date. Fix the mechanics before the content.
Keep the register to a manageable number of active risks — most functional registers at this company size run 20-40 live entries, not hundreds. Every finding does not deserve its own row; group related technical findings under one business risk statement.
Each row needs, at minimum: a plain-language risk statement (not a CVE ID), likelihood and impact scored on a simple 1-5 scale, a single named owner (a person, not a team), a treatment decision (accept, mitigate, transfer, avoid), a due date, and a status. A documented scoring rubric prevents every reviewer from grading on gut feel, which is the fastest way for a register to lose credibility.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanMapping one control set to many frameworks
The biggest efficiency gain in GRC at this stage is realizing that ISO 27001, SOC 2, DPDP obligations, CERT-In directions, and sector rules overlap heavily on the underlying control. Access control, logging, incident response, vendor risk, and encryption show up in nearly every framework — just phrased and evidenced differently. Build one control library and map each control to every framework clause it satisfies, instead of running parallel compliance projects.
ISO/IEC 27001:2022 organizes its controls into four themes — organizational, people, physical, and technological — with 93 controls total. That structure is a reasonable backbone for a unified library because most other frameworks' requirements map cleanly onto one of those four themes.
| Control area | ISO 27001:2022 | SOC 2 | DPDP Act 2023 | CERT-In | RBI/SEBI (regulated only) |
|---|---|---|---|---|---|
| Access control | Org/Tech controls | Logical access | Fiduciary safeguards | — | Access governance |
| Logging | Tech controls | Monitoring | Breach detection | 180-day log retention in India | Logging norms |
| Incident response | Org controls | Incident management | Breach notification | Report within 6 hours | Incident reporting |
| Vendor risk | Org controls | Vendor management | Processor obligations | — | Outsourcing guidelines |
| Data protection | Tech controls | Confidentiality | Core Act + Significant Fiduciary duties | — | Localization/retention rules |
Under the DPDP Act 2023, organizations classified as Significant Data Fiduciaries carry additional obligations, including a Data Protection Officer based in India, an independent data auditor, and periodic data protection impact assessments. Most growing companies aren't classified this way yet, but it's worth checking as your data footprint scales — see our DPDP compliance page for the fuller breakdown.
Evidence collection: the difference between spreadsheet theatre and a real program
The single biggest tell that GRC has become theatre is evidence collected retroactively — screenshots taken the week before an audit, configs pulled from memory of "how it's usually set up," log samples cherry-picked to look clean. Auditors and enterprise security teams can tell the difference, and it affects both audit outcomes and deal cycles.
Continuous evidence collection means the artifacts an auditor needs — access review logs, patch records, vulnerability scan history, incident tickets, vendor due diligence records — accumulate automatically as controls run, timestamped and stored where they cannot be quietly edited later. Automated scanning earns its keep here: a recurring vulnerability assessment produces a dated, reproducible artifact every cycle, rather than a one-time PDF that ages out of relevance within weeks. Bachao.AI, built by Dhisattva AI Pvt Ltd, runs continuous automated VAPT for Indian SMBs and mid-market firms, feeding dated findings directly into a risk register instead of a static report left unopened until next year's audit — and where a CERT-In empanelled entity is specifically required, that is delivered with a CERT-In empanelled partner.
Where GRC effort actually goes in year one
For a company standing up its first real GRC function, year-one effort is rarely evenly split — most goes into risk assessment and control implementation before the program stabilizes into steadier evidence and audit-readiness work.
Illustrative split — actual proportions vary by company size, control maturity, and how many frameworks are in scope.
A practical checklist to start this quarter
- [ ] Draft and get sign-off on a one-page risk appetite statement
- [ ] Build or update the asset and data inventory
- [ ] Stand up a single risk register with a documented scoring rubric and named owners
- [ ] Build one control library mapped to every framework you actually need
- [ ] Confirm whether RBI, SEBI, or Significant Data Fiduciary status applies to your business
- [ ] Set up continuous evidence capture instead of pre-audit collection
- [ ] Put risk register review on a fixed quarterly leadership agenda
GRC is not a certificate you earn once. It is the operating loop that turns leadership's risk appetite into daily control decisions, and those decisions into evidence that a framework — ISO 27001, SOC 2, DPDP, CERT-In, or a sector regulator — will accept. Build the loop once, map it to every framework you need, and audits stop being events and start being checkpoints on a program already running.