NCSRC NIRMATA
Home Guides Framework Start Assessment →
Home › Guides › Infrastructure Security › APS-08
APS-08 Infrastructure Security 12% of OML score

Are applications tested or reviewed before being used for sensitive data?

Before your business starts using any new software or tool to handle sensitive customer or financial data, do you check it first to make sure it's secure and won't cause problems? This question asks whether you have a process to review and test applications before they touch important data.

⚡
Why This Matters to Your Business

If you don't test applications before use, you risk embedding insecure tools deep into your operations, making them expensive and disruptive to remove later. A real example: a Delhi-based export company adopted free accounting software without security review, suffered a data breach exposing GST details of 200+ clients, faced customer trust loss and RBI scrutiny, and spent ₹8 lakhs on remediation. Without pre-deployment review, you also fail audits required by enterprise clients (especially in manufacturing, finance, healthcare), lose contracts, and create compliance gaps under DPDP Act when customer data is compromised.

📊
What Each Maturity Level Looks Like

Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.

Level 0
Absent

You find new software installed on computers with no one able to explain why or when it was approved. Team members download tools from the internet whenever they need something, and there is no record of what applications are even running.

Level 1
Initial

You have a loose list of applications somewhere, and someone asks basic questions like 'does this work?' before use, but there is no formal process. Testing, if it happens, is accidental and not documented anywhere.

Level 2
Developing

You have created a simple checklist of security questions (like 'is it from a trusted vendor?' or 'does it encrypt data?') and someone reviews new applications against it before use. You keep a basic record of approvals, but reviews are not detailed and testing is minimal.

Level 3
Defined

You have a documented application approval process that includes a security assessment form, basic functional testing, and vendor validation. Reviews are logged and someone owns the process, though it may not cover all scenarios or stay consistent.

Level 4
Managed

Your process includes detailed security testing (vulnerability scans, data protection checks, integration testing), vendor security assessments, and written approval sign-off before any sensitive data touches the tool. Records are maintained and the process is audited quarterly.

Level 5
Optimised

You have an automated application inventory system integrated with your security tools, continuous monitoring of approved applications for new vulnerabilities, regular re-certification of tools already in use, and a formal change control process. Security testing is part of your standard delivery pipeline and exceptions are rare.

🚀
How to Move Up — Practical Steps
StepWhat to DoWhoEffort
0 → 1 Create a simple document (Google Sheet or Word file) listing every application your business currently uses for sensitive data (accounting software, CRM, file storage, email, etc.). Assign one person (IT lead or business owner) to be responsible for reviewing any new tool request before it is installed. IT Lead or Business Owner 1-2 days
1 → 2 Draft a one-page application approval form with 8-10 basic security questions: Does the vendor have a privacy policy? Is data encrypted in transit and at rest? What is the vendor's location and compliance status (ISO, SOC2)? Require this form to be completed and kept on file before any new tool handles sensitive data. IT Lead with Input from Finance/Operations Lead 3-5 days
2 → 3 Formalize the approval process into a written policy (2-3 pages). Define who can request tools, who must approve (e.g., IT Lead + Department Head), what testing must happen (functional test + basic security scan), and where records are stored. Conduct a half-day training with your team on the new process. IT Lead with Compliance or HR Lead 2-3 weeks
3 → 4 Implement a security assessment checklist that includes vendor background check (DUNS, registration verification), data classification (what type of data the tool will handle), vulnerability scanning using free tools (OWASP ZAP or Nessus community), and documented testing results. Require sign-off from IT Lead and data owner before deployment. IT Lead with Security Consultant (1-2 days contract work, ~₹5,000-10,000) 4-6 weeks
4 → 5 Integrate application tracking into your IT asset management system, set up monthly vulnerability monitoring for approved tools (using vendor security bulletins and free threat feeds), and conduct quarterly reviews of all applications in use to ensure continued compliance. Document any deprecated or risky tools and plan their replacement. IT Lead with Annual Review by External Auditor Ongoing (2-3 hours/month)
📁
Evidence You Should Have

Documents and records that prove your maturity level.

  • Written Application Approval Policy or Process Document (signed and dated)
  • Application Security Assessment Form or Checklist (completed for each tool handling sensitive data)
  • Vendor Due Diligence Record (privacy policy, compliance certifications, security questionnaire responses from vendor)
  • Testing Report or Log (functional testing, vulnerability scan results, or pen test report before deployment)
  • Application Inventory List (current and historical, showing approval date, responsible person, data classification, and review/renewal dates)
🔍
What an Auditor Will Ask

Prepare for these questions from customers or third-party reviewers.

  • "Walk me through your process for approving a new application before it handles customer data. Who decides, what checks happen, and where is this documented?"
  • "Can you show me the security assessment you did before deploying [specific tool, e.g., your current CRM or file storage system]? What testing was done?"
  • "How do you ensure that applications you approved 2 years ago are still secure and compliant today? Do you re-review or monitor them for vulnerabilities?"
  • "What happened the last time someone wanted to use a new tool? Can you walk me through the approval for that decision with the supporting documents?"
  • "What is your vendor selection criteria, and how do you verify that a vendor's security claims are legitimate (e.g., their ISO certification, data encryption, breach history)?"
🛠
Tools That Work in India
PurposeFree OptionPaid Option
Maintain a simple list of approved applications with version, vendor, and data sensitivity Google Sheets or Microsoft Excel with access controls; LibreOffice Calc Asset management tools like Snipe-IT (₹0-30,000/year depending on scale) or ManageEngine AssetExplorer (₹50,000-200,000/year)
Scan applications and infrastructure for common security vulnerabilities before deployment OWASP ZAP (free, open-source), Nessus Community Edition (free up to 16 IPs), Qualys Community (limited free scans) Qualys VMDR (₹400,000-1,000,000/year), Rapid7 InsightVM (₹500,000-2,000,000/year)
Create and store security assessment forms and approval documentation securely Google Forms + Google Drive, OneDrive, or open-source form tools Jotform (₹4,000-15,000/year), Formstack (₹200,000+/year)
Monitor vendor security updates and known vulnerabilities in approved software NVD (National Vulnerability Database) RSS feeds, GitHub Security Advisories, vendor mailing lists Rapid7 Nexpose monitoring (₹500,000+/year), CrowdStrike Falcon Intelligence (₹600,000-2,000,000+/year)
Document and track application inventory with compliance metadata Spreadsheet with data governance template, open-source CMDB tools ServiceNow CMDB (₹500,000-3,000,000/year), BMC Helix (₹400,000-1,500,000/year)
🛡
How This Makes You More Resilient
When you test applications before deployment, you catch security flaws and compatibility issues early, before they corrupt your data or expose customer information. This means fewer emergency fixes, fewer breach incidents, faster audit pass-throughs, and more stable operations. Your team also spends less time fighting fires and more time on growth.
⚠️
Common Pitfalls in India
  • Assuming that free or popular software (e.g., free CRM tools, open-source databases) is automatically secure. Popularity does not equal security, and free tools may lack vendor support or security updates.
  • Testing only functionality, not security. Your team asks 'does it work?' but never asks 'is it safe?' or 'will it encrypt our data?'. This leaves you vulnerable to breaches that could have been prevented.
  • Approving an application once and never reviewing it again. Vendors release updates, vulnerabilities are discovered, and compliance requirements change. Tools approved 3 years ago may no longer be suitable.
  • Skipping vendor due diligence because the purchase is small. A ₹5,000 tool that handles customer GST data is as risky as a ₹500,000 system. Risk depends on data sensitivity, not cost.
  • Allowing shadow IT (employees downloading tools without permission) because the approval process feels slow. Build a fast-track review (24-48 hours) to reduce workarounds, or you lose visibility entirely.
⚖️
Compliance References
StandardRelevant Section
DPDP Act 2023 Section 8 (Consent and legitimate use) and Section 6 (Processing personal data securely with appropriate safeguards)
CERT-In Guidelines 2022 Practice 5 (Software and security updates), Practice 6 (Third-party software and tools)
ISO 27001:2022 A.5.23 (Information security for supplier relationships), A.8.28 (Secure development policy), A.8.30 (Testing of changes)
NIST CSF 2.0 Govern (GV) - GV.SC-1 (Procedures and processes to manage hardware and software), Protect (PR) - PR.PS-1 (Processes and tools to manage software updates and patches)

Ready to assess your organisation?

Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.

Start Free Self-Assessment →

TRUST-IN Bharat · NIRMATA Framework · Licensed CC BY-SA 4.0 · Custodian: Elytra Security

← Back to all guides  ·  trustinbharat.org