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

Are security settings reviewed when new applications are introduced?

When you buy or install new software or apps for your business, are you checking that the security settings are properly configured before people start using it? Most software comes with default settings that make it easy to use but unsafe, and you need someone to actively harden these before employees access it.

⚡
Why This Matters to Your Business

If you skip this step, attackers can exploit weak default passwords, unnecessary features left enabled, or unpatched vulnerabilities in new applications—often taking weeks before you notice. A textile export company in Tamil Nadu once deployed a new accounting software with default admin credentials still active; a competitor's employee accessed their entire financial database and customer list, costing them ₹25 lakh in lost contracts and legal fees. Regulatory audits by banks or government bodies will fail if they find misconfigured applications, and you could face penalties under DPDP Act if customer data is exposed through a poorly secured app. Your operations also risk disruption if ransomware enters through an unprotected new tool.

📊
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 install new software and people log in immediately using whatever setup the vendor provides. You have no record of what security settings exist or were changed.

Level 1
Initial

Someone (usually the owner or one IT person) remembers to manually check a few obvious settings like passwords on new apps, but there is no consistent process or checklist.

Level 2
Developing

You have a basic written checklist of security settings to review before new software goes live (like changing default passwords, disabling unused features). The IT person follows this sometimes, but it is not enforced every time.

Level 3
Defined

You have a formal documented process that requires security review before any new application is deployed. The IT person or manager signs off on completion, and you keep records of what was checked and changed.

Level 4
Managed

Your security review process is integrated into your procurement workflow. Before purchasing software, you evaluate its security posture; after installation, a second person verifies that settings match your security policy, and findings are logged in a tracking system.

Level 5
Optimised

New application security reviews are automated where possible (vulnerability scans, configuration compliance checks) and reviewed by a security-aware team. Results feed into a continuous improvement process; high-risk misconfigurations trigger immediate remediation, and quarterly audits ensure no drift in settings.

🚀
How to Move Up — Practical Steps
StepWhat to DoWhoEffort
0 → 1 Create a simple one-page checklist of critical security settings (default passwords, user access permissions, encryption options, logging enabled) specific to applications your business uses. Have the IT person or manager review and sign off on this checklist for the next new application deployment. IT person or business owner 1 day
1 → 2 Formalize the checklist into a documented process. Include specific steps for each application type, assign responsibility, and define approval sign-off. Store completed checklists in a folder (physical or shared drive) with dates and names. IT person with approval from business owner 1 week
2 → 3 Integrate the security review process into your application procurement and deployment workflow. Require that no new app goes live until the checklist is completed and signed by both the IT person and a second reviewer (manager or owner). IT person and manager 2-4 weeks (includes training and process adjustment)
3 → 4 Expand your process to include pre-purchase security assessment (vendor documentation review, known vulnerabilities, compliance certifications). Create a tracking spreadsheet or simple database to log all reviews, deviations, and remediation actions. Conduct quarterly spot-checks. IT person with periodic review by senior manager 1-2 months (initial setup; ongoing ~4 hours/month)
4 → 5 Where feasible, implement automated tools for vulnerability scanning and configuration compliance checks on new applications. Establish a cross-functional review board (IT, security, business owner) that meets monthly to review all new application deployments and security findings. Use results to refine your baseline security standards annually. IT person, security consultant, business owner Ongoing (8-12 hours/month for reviews and improvements)
📁
Evidence You Should Have

Documents and records that prove your maturity level.

  • A written application security review checklist that lists critical settings (passwords, permissions, encryption, logging, unnecessary services disabled) for your business
  • Completed and signed checklists for at least 3 recent software deployments in the last 6-12 months, showing what was reviewed and who approved it
  • A documented process or procedure document describing when and how security reviews happen before new applications go live
  • A log or spreadsheet recording all new applications deployed in the past year, dates of security review, any issues found, and remediation actions taken
  • Evidence of training or communication to relevant staff (IT, managers) explaining why these security reviews are required
🔍
What an Auditor Will Ask

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

  • "Walk me through the last three applications you deployed. Show me how you reviewed security settings before users accessed them."
  • "Do you have a documented process for reviewing application security configurations before deployment? Can you show it to me and evidence that it is being followed?"
  • "Who is responsible for ensuring new applications are securely configured, and how do you verify that this person completed the review?"
  • "Have you ever found a misconfiguration or security issue during an application review? What happened, and how was it fixed?"
  • "What happens if someone wants to deploy a new application without completing your security review process? Are there consequences?"
🛠
Tools That Work in India
PurposeFree OptionPaid Option
Create and store security review checklists for applications Google Sheets or LibreOffice Calc (free, cloud-based, easy to share) Microsoft Excel with SharePoint (₹500–2,000/user/year if part of Microsoft 365); Notion (₹200–300/month for team)
Scan new applications for known vulnerabilities and security misconfigurations OWASP Dependency-Check (open source, scans application dependencies); Qualys Community Edition (limited free tier for vulnerability scanning) Rapid7 InsightVM (₹3–5 lakh/year); Qualys VMDR (₹5–10 lakh/year for small teams)
Track and log all new application deployments and their security review status Airtable free tier or Jira Community Edition (for small teams, up to 10 users) ServiceNow (₹4–8 lakh/year); Jira Standard (₹50,000–1,00,000/year)
🛡
How This Makes You More Resilient
With this control in place, you significantly reduce the window of time a new application can be exploited by attackers due to weak default settings. Your business avoids costly data breaches, regulatory fines, and customer trust loss that result from compromised applications. You also make it much harder for unauthorized users (competitors, disgruntled employees, or external attackers) to gain access to sensitive data through poorly secured new software.
⚠️
Common Pitfalls in India
  • Assuming the vendor's default configuration is 'secure enough'—it is almost never true. Vendors prioritize ease of use and broad compatibility over hardening, leaving admin accounts, unnecessary services, and weak encryption enabled by default.
  • Deploying applications on a Friday evening or during off-hours to avoid disrupting work, then not following through with security checks until days or weeks later when the app is already in production and people are using it.
  • Relying on a single person (often the owner's nephew or a junior IT hire) to remember security settings without documented process, training, or accountability. When that person leaves or is busy, critical reviews are skipped.
  • Not reviewing security settings for cloud-based or SaaS applications because 'the vendor handles security.' In reality, shared configurations (IAM, API keys, data sharing settings) still need to be reviewed and hardened by your organization.
  • Creating a checklist but not actually using it consistently—it sits on a shelf while new apps are deployed through shortcuts because people feel the process is 'too slow' or 'bureaucratic.' Without enforcement, the process becomes theater.
⚖️
Compliance References
StandardRelevant Section
DPDP Act 2023 Section 8 (Principles for processing personal data) – requirement to implement reasonable security practices and procedures; Section 4(11) emphasizes minimizing collection and ensuring security
CERT-In Guidelines 2022 Section 3.2 (Secure Software Development and Deployment) – mandates secure configuration management and security review before deployment
ISO 27001:2022 Annex A 8.6 (Management of technical vulnerabilities) and A 5.23 (Information security for supplier relationships); A 6.2 addresses change management security
NIST CSF 2.0 Govern (GV) function – GV.RO-01 (Organizational context and strategy) and GV.SC-01 (Supply chain risk management); Protect (PR) function – PR.MA-01 and PR.MA-02 (Maintenance and configuration management)

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