If you don't regularly review your applications for security flaws, hackers can exploit old vulnerabilities to steal customer data, payment information, or confidential business records. A mid-sized e-commerce company in Bangalore discovered after a breach that their checkout page had a vulnerability from two years ago that was never patched, costing them ₹15 lakh in customer compensation and lost trust. Customers and business partners increasingly ask for proof of security reviews before signing contracts or payment terms. Without documented reviews, you fail audit requirements under DPDP Act and lose contracts worth lakhs.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no record of any security review of your applications. Your IT person updates code when needed but has never formally checked for security problems.
Initial
You did a security review once, maybe two years ago, but there's no documented plan to repeat it. You have some notes or an old email about it, but nothing formal.
Developing
You performed a security review in the last 12 months (documented with a date and some findings), but the review was basic and done informally—perhaps by your developer testing the system themselves without a structured checklist.
Defined
You have annual security reviews documented with findings, a to-do list of fixes, and evidence that you've fixed at least some of the issues found. A senior developer or IT person signs off on the review.
Managed
You conduct formal security reviews every 12 months using a documented process or checklist. Reviews are done by someone independent of the development team. All high-severity findings are tracked, fixed, and re-tested before code goes live.
Optimised
You perform continuous security reviews (every time code changes), use automated scanning tools, conduct reviews at least annually with external auditors or specialists, and maintain a live register of all vulnerabilities found, fixed, and re-tested with dates and sign-offs.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Schedule and conduct a basic security review of your main application: list all user input fields, check if data is encrypted in transit, verify that passwords are hashed, and document findings in a spreadsheet with date and reviewer name. | Developer or IT person | 3-5 days |
| 1 → 2 | Create a written security review checklist covering OWASP Top 10 risks (SQL injection, broken authentication, sensitive data exposure, etc.). Re-run the review using this checklist and document all findings in a formal report with date, findings, and sign-off. | Developer or IT person with technical background | 1-2 weeks |
| 2 → 3 | Establish an annual review schedule. Create a remediation log to track all findings and assign fixes to developers with target dates. Re-test fixed items and mark them closed with evidence (code commit reference, test log). Document the entire process. | IT Manager or Technical Lead | 2-4 weeks |
| 3 → 4 | Hire an external security consultant or auditor to conduct a formal security assessment. Integrate their checklist into your review process. Implement automated vulnerability scanning tools (OWASP ZAP or Burp Suite Community). Establish a policy that reviews happen before each major release. | IT Manager with external consultant | 4-8 weeks |
| 4 → 5 | Deploy automated scanning in your CI/CD pipeline to catch vulnerabilities on every code commit. Establish a bug bounty program (internal or external). Conduct quarterly reviews with an external specialist. Maintain a centralized vulnerability register with SLAs for remediation based on severity. | DevOps Engineer, IT Manager, Security Officer | Ongoing (2-3 hours per week) |
Documents and records that prove your maturity level.
- Signed and dated Application Security Review Report from the last 12 months, with application name, version, date of review, and reviewer identity
- Security checklist or assessment framework used (e.g., OWASP Top 10 checklist, or custom internal checklist), with checkmarks and evidence against each item
- List of findings (vulnerabilities or weaknesses found) with severity levels (Critical, High, Medium, Low), description, and recommendation
- Remediation tracking log showing each finding, the developer/team assigned, target fix date, actual fix date, re-test confirmation, and closure sign-off
- Evidence of fixes applied: code commit logs, test results, or updated deployment records dated after the vulnerabilities were found
Prepare for these questions from customers or third-party reviewers.
- "When was your last application security review conducted, and can you show me the dated report?"
- "What process or checklist do you use to assess security during reviews, and who is responsible for conducting them?"
- "Which vulnerabilities or weaknesses did your most recent review identify, and what is the status of fixes for each one?"
- "How do you ensure reviews happen regularly? Do you have a documented schedule or policy requiring annual (or more frequent) reviews?"
- "Who performed the review—an internal developer, an independent internal team member, or an external specialist—and do they have documented security knowledge?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Automated scanning of web applications for common vulnerabilities (SQL injection, cross-site scripting, etc.) without needing to write code | OWASP ZAP (free, no registration) or Burp Suite Community Edition (free, web-based or download) | Burp Suite Professional (₹60,000–80,000/year), Checkmarx (custom quote, typically ₹15–30 lakh/year for SMEs) |
| Dependency scanning to check if third-party libraries and packages your app uses have known security vulnerabilities | npm audit (if using Node.js), pip check (if using Python), or Snyk CLI (free tier with limited scans) | Snyk (₹80,000–2,00,000/year depending on team size), Black Duck by Synopsys (custom quote) |
| Vulnerability management and tracking: record findings, assign fixes, track remediation status, and generate reports for auditors | Google Sheets template or open-source DefectDojo (self-hosted), Jira for issue tracking | Tenable Nessus (₹3–4 lakh/year), Rapid7 InsightVM (custom quote), or SecurityScorecard (₹5–10 lakh/year) |
- Reviewing only the latest code changes and ignoring the underlying infrastructure, third-party libraries, and backend systems that also have vulnerabilities—a 'surface-level' review that misses real risks
- Assigning the review to the same developer who wrote the code; they miss their own mistakes and may have biases about what is 'safe enough,' rather than having an independent person review with fresh eyes
- Conducting a review once and never updating it, even when your application changes significantly (new payment gateway, new database, new API integrations, or major feature additions)—changes introduce new vulnerabilities that the old review missed
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 6 (Principles), Section 8 (Consent for Processing), and Schedule 1 (Reasonable Security Measures) require periodic security assessments and documentation of controls |
| CERT-In 2022 | Guidelines on Information Security Practices recommend vulnerability assessment and periodic security reviews as part of incident prevention |
| ISO 27001:2022 | Control A.8.24 (secure development and testing environment) and A.14.2 (secure development policy) mandate security reviews and testing before deployment |
| NIST CSF 2.0 | Govern (GV.3) - Cybersecurity roles and responsibilities; Protect (PO.3.2) - Configuration management; and Protect (PO.5) - Access control and authentication |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →