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

Are applications removed or decommissioned when no longer needed?

When your business stops using a software application or system, do you properly shut it down and remove it from your computers and servers? This question checks whether old, unused applications are still sitting around collecting dust—and potentially letting hackers in because nobody is updating or protecting them anymore.

⚡
Why This Matters to Your Business

Old applications that nobody uses anymore are like having broken locks on the back door of your office—hackers know they're neglected and unpatched, making them easy targets. A manufacturing business in Gujarat that kept an old inventory system running 'just in case' suffered a ransomware attack through that forgotten application, lost 2 weeks of production data, and had to pay ₹15 lakhs to recover. Banks and payment processors now ask their vendor MSMEs for proof of decommissioning unused software, and if you can't show it, they may stop doing business with you. Regulators under DPDP can fine you for failing to protect customer data, even if the breach came through an old application you forgot about.

📊
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 have servers and computers running applications from 5+ years ago that nobody remembers how to use or why they're there. When someone leaves the company, their old email account and their access to 3 different systems stays active indefinitely.

Level 1
Initial

You have a rough list of applications somewhere (maybe in an email or notebook), but you're not sure which ones are actually still being used. When you do try to turn something off, people complain because they were actually still using it and nobody told you.

Level 2
Developing

You have a documented list of all business applications with some attempt to note which are active, and you ask users once a year if they still need something. When you decide to remove an application, you give people 2 weeks' notice but don't always verify that data has been backed up first.

Level 3
Defined

You maintain an updated inventory of all applications, with clear ownership and usage status reviewed every 6 months. Before removing any application, you follow a documented decommissioning process: notify users, backup data, remove access accounts, and uninstall software.

Level 4
Managed

Your application inventory is integrated with your IT asset management system and automatically flagged if unused for 6+ months. Decommissioning follows a formal change control process with sign-off; all data is archived securely before removal, and access credentials are fully revoked.

Level 5
Optimised

You have automated monitoring that detects unused applications and generates alerts for your IT team monthly. Decommissioning is fully documented with audit trails, compliance checks, and an automated workflow that ensures no step is skipped; retiring applications triggers security baseline reviews.

🚀
How to Move Up — Practical Steps
StepWhat to DoWhoEffort
0 → 1 Create a simple spreadsheet listing every application, software, and online service your business uses (ERP, email, accounting software, CRM, databases, etc.) and mark whether it's definitely active, probably active, or unknown. IT person or office manager 2–3 days (interview all department heads)
1 → 2 Set up a formal Application Inventory document with columns: name, purpose, owner, last used date, and active/inactive status. Conduct a user survey and mark any app not used in the last 6 months as 'candidate for removal.' IT person with manager approval 1 week
2 → 3 Create a written Decommissioning SOP (Standard Operating Procedure) that includes: 30-day notice to users, data backup verification, account/license cancellation, uninstall steps, and sign-off. Review and update the inventory every 6 months. IT person and department heads 2–3 weeks
3 → 4 Integrate application data into your IT asset management tool (or create a simple database if you don't have one). Build a decommissioning checklist template with automatic notifications. Track who approved removal and archive all removal records. IT person with external consultant if needed 4–6 weeks
4 → 5 Set up automated monthly reports on application usage (via system logs or IT tools) and alerts for apps unused >6 months. Link decommissioning approvals to your change control and security review processes. Train team on the system. IT person and security/compliance lead Ongoing (1–2 hours monthly)
📁
Evidence You Should Have

Documents and records that prove your maturity level.

  • An up-to-date Application Inventory spreadsheet or database with columns for app name, owner, business purpose, last active date, and status (Active/Inactive/Decommissioned)
  • A written Decommissioning Procedure or SOP that documents the steps for removing applications, including user notification, data backup, account removal, and sign-off
  • Decommissioning records for at least 2–3 applications removed in the past 12 months, including evidence of notice to users, data backup confirmation, and removal sign-off
  • Screenshots or logs showing that unused accounts and software have been disabled or uninstalled on your servers and user computers
  • A completed decommissioning checklist or form for any recent application removal, showing who approved it and when
🔍
What an Auditor Will Ask

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

  • "Walk me through your process for identifying and removing applications that are no longer needed. What triggers a decision to decommission something?"
  • "Do you have a list of all business applications currently in use, and how do you verify they are actually still being used?"
  • "Show me records of any applications removed in the last 18 months. How did you ensure data was backed up and user access was fully revoked before deletion?"
  • "What happens when someone leaves your company? How do you ensure their access to old applications is removed?"
  • "Do you ever conduct an audit of your servers or computers to find old software or dormant accounts that might still be running?"
🛠
Tools That Work in India
PurposeFree OptionPaid Option
Track and manage all your applications, hardware, licenses, and when they were last used LibreOffice Calc or Google Sheets with a template for application inventory Jira Service Management (₹7,000–15,000/year for small team); Snipe-IT asset management (₹0–20,000/year depending on deployment)
Monitor which applications and services are actually being used on your network and computers Windows Task Manager (built-in, limited); Linux system logs via grep/awk Lansweeper (₹30,000–80,000/year); Qualys VMDR (₹2–5 lakhs/year for small deployment)
Automate decommissioning workflows and track approvals, backups, and removal steps Microsoft Forms + Excel; Google Forms + Sheets for basic workflows ServiceNow IT Service Management (₹5–10 lakhs/year); Freshservice by Freshworks (₹2–4 lakhs/year for SMB)
🛡
How This Makes You More Resilient
When you properly remove old applications, you eliminate entire invisible entry points that hackers could exploit—they can't attack software that no longer exists. Your business avoids the expensive crisis of a ransomware attack through a forgotten system, keeps your customer trust intact, and passes audits from banks and corporate clients who check for security maturity. You also save money by not paying for unused licenses and not wasting IT effort patching or securing applications that serve no purpose.
⚠️
Common Pitfalls in India
  • Assuming 'nobody is using it' without actually checking—in Indian businesses, sometimes critical old systems are still used by one person in one department and removing them causes operations to crash
  • Not backing up data before removing an application, especially for old accounting or inventory systems—companies later discover they need historical records for GST audits or loan applications and the data is gone forever
  • Removing an application but leaving user accounts and access active—auditors will flag this as a failed decommissioning, and it's a security risk; proper removal means disabling all logins tied to that app
  • Never doing a network scan or desktop audit to find zombie applications—old software installed 'just in case' often sits on servers for years, unpatched and exposed, because the IT person doesn't even know it's there
  • Confusing 'decommissioning' with just 'stopping to use'—many Indian SMEs turn off an application but leave it installed and licensed, still taking resources and creating a security debt
⚖️
Compliance References
StandardRelevant Section
DPDP Act 2023 Section 8 (Purpose Limitation) and Section 9 (Data Minimization) — requires that personal data be processed only for stated purposes and kept only as long as necessary; decommissioning unused systems that hold data supports this obligation
CERT-In Guidelines 2022 Direction 4 (Secure Configuration Management) — mandates inventory of all IT assets and timely removal of obsolete systems to reduce attack surface
ISO 27001:2022 Annex A 5.23 (Information Security for Supplier Relationships) and Annex A 8.1 (User Endpoint Devices) — requires organizations to maintain control over and manage the lifecycle of systems, including safe disposal
NIST CSF 2.0 Govern Function (GV.PO: Portfolio Management) and Protect Function (PR.IP: Information Protection Processes and Procedures) — managing the IT asset inventory and secure configuration

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