Without records, you cannot prove you acted responsibly if something goes wrong. If a data breach happens and a customer or regulator asks what you did to protect their data, you'll have no documented evidence of your decisions. For example, if your business lost customer financial data and the RBI or CERT-In investigates, they'll ask to see your security decision logs—if they don't exist, you look negligent even if you were careful. You also can't learn from past incidents because there's no history to review, and audits become very difficult because auditors cannot verify your claims.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no system for recording security decisions. When something happens, details are discussed verbally or exist only in scattered emails that no one can find later.
Initial
You keep some informal notes—maybe a basic email folder or a shared drive—but there's no standard format and no clear owner responsible for keeping these records organized.
Developing
You maintain a simple log or spreadsheet documenting major security decisions: software purchases, access changes, security incidents. It's not structured, but it exists and people generally add to it.
Defined
You have a structured decision log in a shared spreadsheet or simple database with clear columns: date, decision type, who decided, what was approved, and outcome. It's reviewed periodically and accessible to relevant staff.
Managed
You maintain a formal decision register updated in real time by designated owners for each function (IT, compliance, operations). It includes approval chains, supporting documents, and monthly reviews to catch gaps.
Optimised
You operate a live decision management system with role-based access, automated alerts for missing documentation, quarterly audits, integration with incident logs, and annual third-party verification of completeness and accuracy.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Create a simple shared folder (Google Drive, OneDrive, or local share) labeled 'Security Decisions' and start emailing a summary of every security-related decision (new password manager, firewall rule change, new vendor access, incident response action) to one designated person who saves them there with date and brief description. | Business owner or IT person | 1 day |
| 1 → 2 | Design a simple one-page template in Google Sheets or Excel with columns: Date | Decision Type (e.g., Access Approval, Incident Response, Software Purchase) | Who Decided | What Was Decided | Status (Approved/Pending/Closed). Start filling it retroactively for the last 3 months and going forward. | IT person or office manager | 3–5 days |
| 2 → 3 | Refine the log with mandatory fields: date, decision owner name, description, risk category (if applicable), approval status, and link to supporting documents. Assign one person to review and update it monthly. Share read-only version with management. | IT person and business owner | 2–3 weeks |
| 3 → 4 | Move to a simple database tool or structured Google Form that feeds into a Sheet. Add approval workflow: decisions require sign-off by owner before logging. Create monthly summary report for leadership showing all decisions and any gaps. | IT person with support from compliance or office admin | 4–6 weeks |
| 4 → 5 | Implement a proper decision management platform (if budget allows) with audit trails, access controls, and automated reminders. Link it to incident logs and compliance calendars. Conduct quarterly internal audits and annual third-party review of the log's completeness. | IT person, compliance officer, and external auditor | Ongoing (monthly reviews, quarterly audits) |
Documents and records that prove your maturity level.
- A security decision log or register (spreadsheet, database, or system) with entries for all major decisions made in the last 12 months, including: date, decision type, approver name, and description
- Approval records or sign-off documents for high-risk decisions (new vendor access, major system changes, security incident responses)
- Incident response logs showing what actions were taken, when, and by whom during any security events or suspicious activity
- Access control decision records documenting when permissions were granted or revoked and on whose authority
- Evidence of monthly or quarterly reviews of the decision log (e.g., a summary email or meeting note showing someone reviewed what was recorded)
Prepare for these questions from customers or third-party reviewers.
- "Can you show me your log of security decisions made over the last year? Walk me through a few recent entries and the supporting documents."
- "When you discovered a security issue or received a complaint about data, what did you do and when? Can you show me written proof of your response actions?"
- "How do you ensure that security decisions are actually recorded? Who is responsible, and how often is the log reviewed?"
- "If a customer asks you to prove you protected their data responsibly, what documentation would you show them right now?"
- "Have you ever had a situation where you could not remember or prove what security decision was made? If so, how did you handle it?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Create and maintain a simple decision log | Google Sheets (free with Google account) or Microsoft Excel online (free with Outlook email) | Airtable (₹5,000–15,000/year for small teams); Smartsheet (₹20,000+/year) |
| Organize and version-control decision documents | Google Drive or Microsoft OneDrive (free with email account) | Notion (₹0–10,000/year depending on plan); Confluence (₹10,000–30,000/year for teams) |
| Track and document incident responses automatically | Google Forms (free) feeding into Google Sheets | Incident.io (₹15,000–40,000/year); PagerDuty (₹25,000–80,000/year for small orgs) |
- Starting a log but not keeping it updated: teams create a spreadsheet, use it for 2 months, then forget. Assign one specific person and check monthly to prevent this.
- Keeping records only for incidents, not routine decisions: auditors look for proof of regular security diligence (access approvals, software reviews, policy updates), not just crisis logs. Include everything.
- No approval trail: recording a decision without showing who approved it is almost useless. Always capture name, date, and sign-off, even if informal.
- Losing context: writing 'Access approved' with no detail about which user, which system, or why. Future you won't remember—make every entry self-explanatory.
- Storing records unsecurely: keeping decision logs in an unencrypted email folder or unprotected spreadsheet defeats the purpose. Ensure the log itself is secured and backed up.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8 (Principles for lawful processing) and Schedule 2 (Obligations of Data Processor) require organizations to maintain records demonstrating compliance with data protection obligations |
| CERT-In Guidelines 2022 | Rule 4(d) requires entities to maintain incident and security event logs; Rule 7 requires documentation of security practices and incident response actions |
| ISO 27001:2022 | Clause A.5.1 (Management responsibility) and A.5.2 (Information security policies) require documented security decisions; Annex A.5.3 requires documented authorization processes |
| NIST CSF 2.0 | Function GV (Governance) and Category GV.OC-01 (Organizational context documented); Category GV.RM-01 (Risk management strategy) requires documented risk decisions |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →