ISO 27001 A.8.19: Installation of Software on Operational Systems

Quick Reference (60 Seconds)

Bottom Line: Every software installation on operational systems is a potential attack vector. A.8.19 is your gatekeeper, controlling who can install what, ensuring only approved software enters your environment, and detecting/removing anything unauthorized.

What the Standard Actually Requires

Figure · Process

What A.8.19 asks you to do

ISO 27001:2022 states:

ISO 27001:2022 Annex A 8.19 asks organizations to securely control how software gets installed onto production systems.

ISO 27002:2022 guidance covers:

1. Software inventory, Know what is installed
2. Approval process, Only approved software allowed
3. Rights restriction, Only authorized users can install
4. Malware scanning, Scan before installation
5. Integrity verification, Verify hashes/signatures
6. Change management, Software changes go through CAB
7. Documentation, Record all installations
8. Monitoring, Detect unauthorized installations
9. Removal, Remove unauthorized software promptly
10. Mobile code control, Manage Java, ActiveX, scripts
11. Open source assessment, Assess third-party and OSS risks

Why This Control Matters

The Threat

Unauthorized software is the entry point for most malware: trojans disguised as PDF converters, backdoors in "free" tools, cryptominers in pirated software, ransomware via unpatched applications.

Key Statistics

• 95% of malware infections begin with unauthorized software installation (Symantec)
• 70% of organizations have experienced unauthorized software on their networks (Gartner)
• Shadow IT accounts for 30–40% of enterprise software spend (Gartner)
• Supply chain attacks increased 742% (Sonatype)
• Open source vulnerabilities exist in 85% of commercial codebases (Synopsys)
• India ranks 3rd globally in malware infections

Real-World Incidents

• Mumbai Bank (2024): Customer service rep installed a "free PDF converter" that was a trojan. 10,000 customer records stolen. RBI penalty: .
• Delhi Hospital (2023): Radiologist installed a "free image viewer" with a backdoor. Ransomware encrypted all medical images. No approval process, no inventory.
• Bangalore IT Services (2024): Developer installed an unapproved GitHub tool with a known CVE. Attacker injected malicious code into a client project. ISO 27001 certification lost.
• Chennai Manufacturing (2023): Engineer installed pirated PLC software containing a cryptominer. 80% CPU consumed for 3 months. Production loss: .
• Government Department (2024): Clerk installed a "free typing tutor" that installed adware. Media embarrassment, MeitY intervention required.

Regulatory Drivers

• RBI Cyber Security Framework mandates software inventory and controls
• SEBI Cybersecurity Circular requires change control for trading systems
• PCI DSS v4.0 Requirements 6.5 and 11.5.2 require inventory and unauthorized installation detection
• CERT-In recommends application whitelisting for critical infrastructure
• DPDP Act 2023 requires data fiduciaries to protect systems
• SOC 2 CC6.1 and CC7.1 require software controls

Scope and Applicability

Covered

• All software on operational systems: servers, workstations, network devices, cloud resources, containers, mobile devices
• Operating systems, patches, firmware updates
• Business applications, middleware, databases, security tools
• Development tools, cloud CLI tools, container tools
• Mobile code, browser extensions, mobile apps
• Open source libraries, dependencies, packages
• Third-party software, contractor-provided software
• Scripts, automation, scheduled tasks
• Updates, upgrades, temporary software, trial software
• Personal software and shadow IT

Not Typically Covered

• Pre-installed vendor software (but must be inventoried)
• Development/test environment software (subject to A.8.31)
• Personal devices not used for business (BYOD policy applies)

Applicability by Sector

Key Definitions

Relationship to Other Controls

Implementation Roadmap

Week 1: Assessment and Planning

• Days 1–2: Audit current software on all operational systems using discovery tools ( Lansweeper, Microsoft SCCM, Open-AudIT)
• Days 3–4: Categorize discovered software into approved, unauthorized, unknown, and shadow IT
• Days 5–7: Draft software installation policy and procedure; define approval workflow
• Deliverables: Software inventory report, policy draft, approval workflow design

Week 2: Baseline and Rights Restriction

• Days 1–3: Define software baseline for each system type (server, workstation, network device)
• Days 4–5: Remove local admin rights from standard users (Windows UAC, Linux sudo restrictions)
• Days 6–7: Deploy application control tools (AppLocker, WDAC, or third-party EDR with application control)
• Deliverables: System baselines, restricted admin rights, application control deployed

Week 3: Approval and Distribution

• Days 1–3: Create approved software catalog and self-service portal (or IT ticket-based request system)
• Days 4–5: Implement change management integration (software installation requests flow through CAB or standard change process)
• Days 6–7: Deploy software distribution system (Microsoft Intune, SCCM, Jamf, or open-source alternatives)
• Deliverables: Software catalog, change integration, distribution system deployed

Week 4: Verification and Monitoring

• Days 1–3: Implement malware scanning for all software before installation (integrate with antivirus/EDR)
• Days 4–5: Implement integrity verification (hash checks, code signature validation)
• Days 6–7: Deploy monitoring for unauthorized installation attempts (SIEM alerts, FIM alerts)
• Deliverables: Malware scanning, integrity verification, monitoring alerts

Week 5–6: Cleanup and Hardening

• Days 1–7 (Week 5): Remove all unauthorized software from operational systems; quarantine suspicious software
• Days 1–7 (Week 6): Harden package managers (trusted repositories, GPG verification, lock files); restrict mobile code execution (Java, ActiveX, browser extensions)
• Deliverables: Cleaned systems, hardened package managers, mobile code restrictions

Week 7–8: Documentation and Training

• Days 1–4: Document all procedures, baselines, and configurations
• Days 5–7: Train IT staff, system administrators, and end-users on the new software installation policy
• Deliverables: Complete documentation, training records, knowledge base articles

Ongoing: Monitoring and Improvement

• Monthly: Review software inventory for unauthorized additions; run drift detection
• Quarterly: Review and update approved software catalog; assess open source vulnerabilities with SCA tools
• Annually: Full software audit; license true-up; review and update policy

Detailed Implementation Guidance

Software Inventory and Discovery

Objective: Know every piece of software on every operational system.

Steps:

1. Deploy discovery tools: Use automated asset discovery tools (Lansweeper, Open-AudIT, Microsoft SCCM, Qualys Asset Inventory, or Flexera) to scan all endpoints
2. Manual verification: For critical systems (air-gapped, ICS, legacy), supplement automated discovery with manual verification
3. Cloud and container discovery: Use cloud-native tools (AWS Systems Manager, Azure Monitor, GCP Asset Inventory) and container scanners (Trivy, Snyk Container, Aqua Security) to inventory cloud resources and container images
4. Open source dependency inventory: Use SCA tools (Snyk, Mend, OWASP Dependency-Check, Sonatype Nexus IQ) to inventory all open source libraries and dependencies in applications
5. Document and categorize: Record software name, version, vendor, license type, installation date, system name, and business justification. Categorize as: Approved, Unauthorized, Unknown, Shadow IT, Legacy/EOL, Open Source

Tools: Lansweeper, Open-AudIT, Microsoft SCCM, Qualys, Flexera, Snyk, Mend, Trivy

Indian context: Many Indian organizations use a mix of Windows, Linux, and legacy systems. Ensure your discovery tool supports all platforms. For value-focused organizations, Open-AudIT (open source) and Lansweeper (free tier) are good starting points.

Software Approval Process

Objective: Only approved software is installed on operational systems.

Steps:

1. Define approval criteria: Business need, security assessment, license compliance, vendor reputation, support availability, compatibility with existing systems
2. Create a software request form: Include fields for: software name, version, vendor, business justification, number of users, system requirements, security assessment, license type, overhead
3. Establish approval workflow:
   • Level 1 (IT): Technical feasibility, compatibility, license check
   • Level 2 (Security): Security assessment, malware scan, vulnerability check
   • Level 3 (Management): Business justification, budget approval, risk acceptance
4. Maintain approved software catalog: A curated list of pre-approved software that users can request through a self-service portal or IT ticket
5. Standard changes: Pre-approved software updates (e.g., Windows Update, approved antivirus updates) can follow a standard change process without CAB review
6. Normal changes: New software installations require CAB or designated approver review
7. Emergency changes: Critical security patches can follow an emergency change process with post-approval documentation

Tools: ServiceNow, Jira Service Management, Freshservice, ManageEngine ServiceDesk Plus, GLPI (open source)

Indian context: For small and growing companies, a simple IT ticket-based approval workflow in Freshservice or Jira Service Management (starting at /user/month) is sufficient. For enterprises, ServiceNow provides full ITSM integration.

Restricting Installation Rights

Objective: Only authorized users can install software on operational systems.

Steps:

1. Remove local admin rights: Standard users should not have local administrator or root privileges
   • Windows: Use Group Policy to remove users from the Administrators group; enforce UAC prompts for all elevation requests
   • Linux: Restrict sudo access using /etc/sudoers; require password for sudo; use sudo logging
   • macOS: Use standard user accounts; require admin password for software installation
2. Application control:
   • Windows: AppLocker (built-in) or Windows Defender Application Control (WDAC), define rules based on publisher, path, or hash
   • Linux: SELinux or AppArmor policies; restrict execution in /tmp and user directories
   • macOS: Gatekeeper (allows only signed software); System Integrity Protection (SIP) prevents modifications to system files
3. Mobile device management:
   • iOS: MDM restricts app installation to the App Store or corporate apps; prevent sideloading
   • Android: MDM restricts app installation to Google Play or approved sources; disable "Unknown sources"
4. Cloud and container environments:
   • Use IAM policies to restrict who can deploy containers or modify infrastructure
   • Implement pod security policies or OPA/Gatekeeper to prevent unauthorized container images
   • Restrict package manager access in production containers (remove apt, npm, pip from production images)

Tools: Microsoft Intune, Jamf, VMware Workspace ONE, MobileIron, SOTI, 42Gears, Microsoft AppLocker, WDAC, SELinux, AppArmor, OPA Gatekeeper, Kyverno

Indian context: Many Indian organizations rely on Windows desktops with local admin rights. Removing these rights is often the single most impactful security improvement. Use a phased approach: start with non-critical users, then expand. Communicate clearly to avoid productivity disruption.

Malware Scanning Before Installation

Objective: All software is scanned for malware before it is installed on operational systems.

Steps:

1. Centralized scanning: All software downloads and installers must be scanned by the organization's antivirus/EDR before execution
2. Endpoint scanning: EDR should automatically scan any file downloaded or executed on endpoints
3. Email scanning: All email attachments should be scanned before delivery (A.8.7)
4. Web filtering: Block known malicious download sites and categories (A.8.23)
5. Sandbox analysis: For high-risk or unknown software, use sandbox analysis (e.g., Any.Run, Joe Sandbox, or on-premise sandbox) to observe behavior before approval
6. Hash verification: Compare software hashes against known good hashes from the vendor

Tools: CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, Kaspersky, Symantec, McAfee, Any.Run, Joe Sandbox, Cuckoo Sandbox

Indian context: Indian organizations often use a mix of international and domestic antivirus solutions. Kaspersky, Quick Heal, and Seqrite are popular in India. Ensure the chosen solution provides centralized management and reporting for compliance audits.

Integrity Verification

Objective: Verify that software has not been tampered with before installation.

Steps:

1. Code signature verification: Verify digital signatures on all executables, installers, and updates
   • Windows: Use signtool verify or PowerShell Get-AuthenticodeSignature
   • Linux: Verify GPG signatures on packages (rpm -K, dpkg-sig --verify)
   • macOS: Gatekeeper verifies signatures automatically; use codesign -v for manual verification
2. Hash verification: Compare SHA-256 or SHA-512 hashes of downloaded software against vendor-published hashes
   • Document the hash verification process in the software approval procedure
3. Repository signing: Ensure all internal software repositories use GPG keys or HTTPS with certificate pinning
4. Container image signing: Use Docker Content Trust, Notary, or Sigstore/cosign to sign and verify container images
5. SBOM verification: For critical software, verify the SBOM against the actual installed components

Tools: Sigstore/cosign, Docker Content Trust, Notary, GPG, OpenSSL, Microsoft signtool, PowerShell

Indian context: Many Indian organizations download software from vendor websites without verifying hashes. Train IT staff to always verify hashes, especially for security patches and firmware updates. For air-gapped systems, verify hashes on a connected system before transferring to the isolated network.

Change Management Integration

Objective: All software installations are controlled through the change management process.

Steps:

1. Categorize software changes:
   • Standard change: Pre-approved, low-risk, routine (e.g., approved antivirus updates, Windows Update patches)
   • Normal change: Requires assessment and approval (e.g., new business application, middleware upgrade)
   • Emergency change: Implemented immediately, documented retrospectively (e.g., critical security patch, outage fix)
2. Change request content: Software name, version, business justification, risk assessment, impact analysis, rollback plan, testing results, approval signatures
3. CAB review: For normal changes, the CAB (or designated approver) reviews the security assessment, compatibility, and business need before approval
4. Implementation window: Schedule installations during approved maintenance windows to minimize business impact
5. Post-implementation review: Verify successful installation, document any issues, update the software inventory

Tools: ServiceNow Change Management, Jira Service Management, Freshservice, ManageEngine, BMC Remedy, GLPI

Monitoring and Detection

Objective: Detect unauthorized software installation attempts in real-time.

Steps:

1. SIEM integration: Forward all software installation events (Windows Event ID 11707, 11708, 11724; Linux package manager logs; macOS installation logs) to the SIEM
2. Alerting rules: Create alerts for:
   • Software installation by non-admin users
   • Installation of software not in the approved catalog
   • Installation from untrusted sources (non-HTTPS, unknown domains)
   • Multiple installation attempts in a short time (potential malware)
   • Execution of unsigned or untrusted software
3. File Integrity Monitoring (FIM): Monitor critical directories (e.g., /usr/bin, /usr/local/bin, C:\Program Files, C:\Windows) for unauthorized file additions
4. EDR behavioral detection: Use EDR to detect suspicious behavior (e.g., installer running PowerShell, installer making network connections, installer modifying registry run keys)
5. Drift detection: Compare current system state against the approved baseline weekly; alert on deviations

Tools: Splunk, IBM QRadar, Microsoft Sentinel, Elastic SIEM, Wazuh, OSSEC, AIDE, Tripwire, CrowdStrike, SentinelOne

Indian context: Many Indian organizations are moving to cloud-based SIEMs (Microsoft Sentinel, Splunk Cloud) to avoid on-premise infrastructure overhead. For budget-conscious organizations, Wazuh (open source) provides SIEM and FIM capabilities free.

Unauthorized Software Removal

Objective: Promptly detect and remove unauthorized software from operational systems.

Steps:

1. Automated detection: Use application control tools to automatically block unauthorized software execution
2. Quarantine: When unauthorized software is detected, quarantine the system or file for analysis rather than immediately deleting (to preserve evidence)
3. Removal procedure: Documented procedure for removing unauthorized software, including:
   • Uninstalling the software
   • Removing residual files, registry entries, or configuration
   • Scanning for malware or backdoors that may have been installed
   • Reviewing system logs for evidence of compromise
   • Reimaging the system if the compromise is severe
4. Incident response: Treat unauthorized software as a potential security incident; follow the incident response procedure (A.5.24–A.5.26)
5. Recurring offenders: Track which users or systems repeatedly have unauthorized software; address the root cause (training, rights restriction, policy enforcement)

Tools: Same as monitoring tools; add system reimaging tools (Microsoft MDT, Clonezilla, FOG)

Mobile Code Control

Objective: Control mobile code (Java, ActiveX, JavaScript, scripts) that can execute on operational systems.

Steps:

1. Browser controls:
   • Disable Java and ActiveX in browsers (both are largely deprecated but may still exist in legacy environments)
   • Restrict browser extensions and plugins to approved ones only
   • Use browser policies (Chrome Enterprise, Firefox ESR, Microsoft Edge policies) to control extension installation
2. Script execution:
   • Use Windows AppLocker or WDAC to restrict script execution (PowerShell, VBScript, batch files)
   • Use PowerShell Constrained Language Mode to restrict PowerShell to approved commands
   • Use Linux AppArmor or SELinux to restrict script execution
   • Disable macros in Office documents by default (A.8.7)
3. JavaScript frameworks: Assess and approve JavaScript frameworks used in web applications; monitor for known vulnerabilities

Tools: Chrome Enterprise, Firefox ESR, Microsoft Edge, AppLocker, WDAC, PowerShell Constrained Language Mode, AppArmor, SELinux

Open Source and Third-Party Software Risk Assessment

Objective: Assess and manage risks from open source and third-party software before installation.

Steps:

1. Vendor assessment: For commercial software, assess the vendor's security practices, reputation, support lifecycle, and financial stability
2. Open source assessment:
   • Check the project's maintenance status (last commit, number of maintainers, community health)
   • Check for known vulnerabilities (CVEs, NVD, OSV)
   • Check the license (GPL, MIT, Apache, etc.) for compliance with organizational policy
   • Check for signs of malicious activity (sudden maintainer changes, suspicious commits, typosquatting)
3. SCA scanning: Run SCA tools on all applications to identify open source dependencies and their vulnerabilities
4. Dependency management:
   • Use lock files (package-lock.json, Pipfile.lock, Cargo.lock, go.sum) to pin exact dependency versions
   • Use private registries (Artifactory, Nexus, GitHub Packages) to cache and control dependencies
   • Scan dependencies for typosquatting and dependency confusion attacks
5. SBOM generation: Generate and maintain SBOMs for all applications; use SBOMs to track vulnerabilities across the software supply chain

Tools: Snyk, Mend (formerly WhiteSource), OWASP Dependency-Check, Sonatype Nexus IQ, FOSSA, Black Duck, Syft, Grype, Trivy, OSV

Indian context: Indian software companies heavily rely on open source. The Log4j (Log4Shell) vulnerability in 2021 affected thousands of Indian organizations. Implement SCA tools and SBOM generation as a priority. The Indian government has also mandated SBOMs for critical software under CERT-In guidelines.

Tools and Technologies

Software Inventory and Discovery

Application Control

Software Distribution

Malware Scanning and EDR

SCA and SBOM

SIEM and Monitoring

Policy Templates

Software Installation Policy (Template)

1. PURPOSE
   To control the installation of software on operational systems to prevent
   unauthorized, malicious, or unapproved software from compromising security.

2. SCOPE
   This policy applies to all software installed on operational systems, including
   servers, workstations, network devices, cloud resources, containers, and mobile
   devices.

3. POLICY STATEMENTS
   3.1 Only approved software may be installed on operational systems.
   3.2 Only authorized personnel with appropriate privileges may install software.
   3.3 All software must be scanned for malware and verified for integrity before installation.
   3.4 All software installations must be documented and approved through the change
       management process.
   3.5 Unauthorized software must be detected and removed promptly.
   3.6 Open source and third-party software must be assessed for security risks before
       approval.
   3.7 Mobile code (Java, ActiveX, scripts) must be controlled and restricted.
   3.8 Software must be kept up to date with security patches.
   3.9 End-of-life and unsupported software must be retired or replaced.

4. ROLES AND RESPONSIBILITIES
   4.1 CISO: Owns the policy, ensures compliance, reports to management.
   4.2 IT Operations: Maintains software inventory, manages distribution, restricts
       installation rights.
   4.3 Security Operations: Scans software for malware, monitors for unauthorized
       installations, investigates incidents.
   4.4 Change Manager: Manages software change requests and CAB reviews.
   4.5 End Users: Must not install unauthorized software; must request software through
       the approved process.

5. APPROVAL PROCESS
   5.1 Standard Change: Pre-approved software updates (e.g., Windows Update, antivirus
       updates) follow the standard change procedure.
   5.2 Normal Change: New software installations require a change request, security
       assessment, and CAB approval.
   5.3 Emergency Change: Critical security patches may be installed immediately with
       retrospective documentation and approval.

6. ENFORCEMENT
   Violations of this policy may result in disciplinary action, including termination.
   Unauthorized software installation that causes a security incident may result in
   legal action.

7. REVIEW
   This policy shall be reviewed annually or after any significant security incident.

Software Installation Procedure (Template)

1. SOFTWARE REQUEST
   1.1 User submits a software request form or ticket via the IT service desk.
   1.2 The request includes: software name, version, vendor, business justification,
       number of users, and system requirements.

2. INITIAL ASSESSMENT (IT Operations)
   2.1 Verify technical feasibility and compatibility with existing systems.
   2.2 Check if the software is already in the approved catalog.
   2.3 If already approved, proceed to installation (standard change).
   2.4 If not approved, forward to Security Operations for security assessment.

3. SECURITY ASSESSMENT (Security Operations)
   3.1 Scan the software installer for malware using the organization's antivirus/EDR.
   3.2 Verify the digital signature and hash of the software.
   3.3 Check for known vulnerabilities (CVEs) in the software and its dependencies.
   3.4 For open source software, assess the project's health, license, and maintenance.
   3.5 Document the security assessment findings.
   3.6 If the software passes the security assessment, forward to the Change Manager.
   3.7 If the software fails, reject the request and notify the user with the reason.

4. CHANGE MANAGEMENT (Change Manager)
   4.1 For standard changes (pre-approved software), schedule installation during the
       next maintenance window.
   4.2 For normal changes, submit the change request to the CAB for review.
   4.3 The CAB reviews the business justification, security assessment, impact analysis,
       and rollback plan.
   4.4 If approved, schedule the installation during an approved maintenance window.
   4.5 If rejected, document the reason and notify the requester.

5. INSTALLATION
   5.1 Install the software using the approved software distribution system or manual
       installation procedure.
   5.2 Verify the installation was successful and the software is functioning correctly.
   5.3 Update the software inventory with the new installation details.
   5.4 Document the installation in the change record and system documentation.

6. POST-INSTALLATION
   6.1 Conduct a post-implementation review to verify success and identify any issues.
   6.2 Monitor the system for any unusual behavior or performance issues.
   6.3 Update the software baseline for the affected system.
   6.4 Close the change request and update the knowledge base.

7. UNAUTHORIZED SOFTWARE DETECTION AND REMOVAL
   7.1 Automated tools monitor for unauthorized software installation attempts.
   7.2 If unauthorized software is detected:
       a. Quarantine the system or file for analysis.
       b. Uninstall the unauthorized software.
       c. Remove residual files, registry entries, or configuration.
       d. Scan the system for malware or backdoors.
       e. Review system logs for evidence of compromise.
       f. If compromise is confirmed, initiate the incident response procedure.
   7.3 Document the detection and removal in the incident log.
   7.4 Update the user and their manager on the incident and required actions.

Risk Assessment

Risk Scenarios

Risk Treatment Options

Audit Checklist

Internal Audit Questions (20 Questions)

1. Is there a documented software installation policy? (A.8.19)
2. Is the policy approved by management and communicated to all relevant personnel? (A.5.1)
3. Is there a maintained inventory of all software installed on operational systems? (A.8.19)
4. Is the inventory accurate and up to date (verified within the last quarter)? (A.8.19)
5. Is there an approved software catalog? (A.8.19)
6. Is there a formal approval process for software installation? (A.8.19)
7. Are all software installations approved before implementation? (A.8.19)
8. Is the approval process integrated with change management? (A.8.19)
9. Are standard changes (pre-approved updates) documented and periodically reviewed? (A.8.19)
10. Are local administrator/root privileges restricted to authorized personnel only? (A.8.2)
11. Are application control tools (AppLocker, WDAC, SELinux) deployed on operational systems? (A.8.19)
12. Is all software scanned for malware before installation? (A.8.7)
13. Is software integrity verified (digital signatures, hash checks) before installation? (A.8.19)
14. Are open source and third-party software assessed for security risks before approval? (A.8.19)
15. Are software installation events logged and monitored? (A.8.15)
16. Are unauthorized software installations detected and removed promptly? (A.8.19)
17. Is there a documented procedure for removing unauthorized software? (A.8.19)
18. Are mobile code controls (browser extensions, script execution) implemented? (A.8.19)
19. Is software kept up to date with security patches? (A.8.8)
20. Are EOL/unsupported software identified and tracked for replacement? (A.8.19)

Evidence to Review

• Software installation policy and procedure (documented, approved, dated)
• Software inventory (current, complete, verified)
• Approved software catalog (current, accessible to users)
• Software request forms (sample of last 12 months)
• Change records for software installations (sample of last 12 months)
• CAB meeting minutes (for normal changes)
• Application control configuration (AppLocker policies, WDAC policies, SELinux policies)
• Malware scanning reports for software installers
• Integrity verification records (hash checks, signature verification)
• Open source assessment records (SBOMs, SCA reports)
• SIEM/EDR alerts for unauthorized installation attempts
• Incident records for unauthorized software detections
• Software removal records (quarantine, uninstall, reimage)
• User access reviews (admin rights, installation privileges)
• Training records for software installation policy
• Vendor security assessment records
• License compliance records
• EOL software tracking list
• Patch management records

Metrics and KPIs

Effectiveness Metrics

Reporting Dashboard

Monthly Security Operations Report:

• Unauthorized software detections (count, systems, types)
• Malware scan results (clean, infected, quarantined)
• Software installation requests (approved, rejected, pending)
• Open source vulnerabilities (critical, high, medium, low)
• Patch compliance status (compliant, non-compliant, EOL)
• Application control blocks (count, types, users)

Quarterly Management Review:

• Software inventory accuracy trend
• impact of unauthorized software incidents
• License compliance status optimization
• Shadow IT discovery and remediation
• EOL software retirement progress
• Open source risk assessment summary
• SBOM coverage and maturity

Common Pitfalls and How to Avoid Them

Pitfall 1: "We Trust Our Users"

Mistake: Assuming employees will not install unauthorized software because they are trustworthy. Reality: Even well-meaning users install "helpful" tools that turn out to be malicious. Trust is not a control. Solution: Implement technical controls (application whitelisting, admin rights removal) that do not rely on user behavior. Train users on the risks and the approved process.

Pitfall 2: "Application Whitelisting Is Too Complex"

Mistake: Avoiding application whitelisting because it seems difficult to maintain. Reality: Modern tools (WDAC, AppLocker with default allow rules) make whitelisting manageable. The security benefit is enormous. Solution: Start with a default-deny approach for critical systems (servers, finance workstations). Use publisher-based rules for common software (Microsoft, Adobe, Google). Gradually expand coverage. Use audit mode before enforcement.

Pitfall 3: "We Only Need to Worry About Windows"

Mistake: Focusing software controls only on Windows endpoints. Reality: Linux servers, macOS workstations, cloud VMs, and containers are equally vulnerable to unauthorized software. Solution: Extend controls to all platforms. Use SELinux/AppArmor for Linux, Gatekeeper for macOS, IAM policies for cloud, and admission controllers for Kubernetes.

Pitfall 4: "Open Source Is Free and Safe"

Mistake: Assuming open source software is inherently secure because the source code is visible. Reality: Open source has vulnerabilities (Log4j, Heartbleed, Shellshock). Many projects are under-maintained. Typosquatting and dependency confusion are real threats. Solution: Implement SCA tools, generate SBOMs, use private registries, pin dependency versions with lock files, and monitor for vulnerabilities continuously.

Pitfall 5: "We Can Patch Later"

Mistake: Delaying software patches because of operational concerns. Reality: Unpatched software is the primary entry point for ransomware and exploits. WannaCry, NotPetya, and EternalBlue all exploited unpatched systems. Solution: Implement a risk-based patching strategy. Critical patches within 24–48 hours. High-risk patches within 1 week. Test patches in a staging environment before production deployment. Use emergency change procedures for critical patches.

Pitfall 6: "We Don't Need to Inventory Cloud Software"

Mistake: Ignoring cloud resources and SaaS applications in the software inventory. Reality: Shadow IT in the cloud is a major risk. Unauthorized SaaS apps can store sensitive data outside organizational control. Solution: Use cloud asset inventory tools (AWS Systems Manager, Azure Resource Graph, GCP Asset Inventory) and CASB tools (Microsoft Defender for Cloud Apps, Netskope, Zscaler) to discover and control cloud software.

Pitfall 7: "Contractors Can Install What They Need"

Mistake: Giving contractors full admin rights without restrictions. Reality: Contractors may install unapproved tools, pirated software, or inadvertently introduce malware. Solution: Use temporary, restricted accounts for contractors. Require software approval for any installation. Monitor contractor activity with session recording. Use jump boxes for contractor access.

Pitfall 8: "We Only Need to Check Once"

Mistake: Performing a one-time software inventory and never updating it. Reality: Software is constantly changing. New installations, updates, and unauthorized additions happen daily. Solution: Automate continuous inventory discovery. Run weekly drift detection. Integrate installation events with the SIEM. Review the inventory quarterly.

Pitfall 9: "Removing Admin Rights Will Break Everything"

Mistake: Fear of removing admin rights because of legacy applications that require them. Reality: Most applications do not need admin rights. Those that do can often be configured to run with elevated privileges via application control or privilege management tools. Solution: Use a privilege management tool (BeyondTrust, CyberArk Endpoint Privilege Manager) to elevate specific applications without giving full admin rights. Test applications in a pilot group before broad deployment.

Pitfall 10: "We Don't Have Budget for Tools"

Mistake: Believing that software control requires premium-tier enterprise tools. Reality: Many effective controls are free or lightweight: AppLocker, WDAC, SELinux, AppArmor, Open-AudIT, Wazuh, OWASP Dependency-Check, Syft, Grype, Trivy. Solution: Start with free tools and built-in OS features. Gradually invest in commercial tools as the organization grows. The impact of a breach far exceeds the impact of tools.

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian Growing-company IT Services Company, "From Open Door to Fortified"

Organization: A 200-employee IT services company in Pune, providing software development and support to clients in the US and Europe. ISO 27001 certified but with a weak A.8.19 implementation.

Solution: The company engaged Singahi to implement A.8.19 controls:

1. Week 1: Deployed Lansweeper to inventory all software. Discovered 847 unauthorized software instances across 200 workstations, including 23 pirated tools, 15 unknown browser extensions, and 47 unapproved open source utilities.
2. Week 2: Removed local admin rights from all developers. Deployed AppLocker with default-deny rules on all workstations. Approved a catalog of 45 essential development tools.
3. Week 3: Implemented a software request workflow in Jira Service Management. All new software requests required security team approval. Deployed Snyk for SCA scanning of all code repositories.
4. Week 4: Integrated software installation events into the SIEM (Wazuh). Configured alerts for unauthorized installation attempts. Removed all unauthorized software.
5. Week 5–8: Trained all developers on the new policy. Generated SBOMs for all client projects. Implemented container image signing with cosign.

Results:

• Unauthorized software instances: 847 → 0 (within 6 weeks)
• Software installation incidents: 3 per month → 0 (ongoing)
• Open source vulnerabilities: 234 critical/high → 12 (remediated within 90 days)
• Client confidence: Restored. The company retained all clients and won 2 new contracts based on improved security posture.
• ISO 27001 surveillance audit: Passed with zero non-conformities for A.8.19.

Quote from the CTO: "We thought our developers needed freedom to be productive. We learned that freedom without controls is a liability. Singahi helped us implement controls that actually made our developers more productive by standardizing tools and eliminating the chaos of 'works on my machine.'"

Illustrative Scenario 2: Large Indian Manufacturing Enterprise, "Securing the OT-IT Boundary"

Organization: A 5,000-employee manufacturing group in Gujarat, with 12 plants across India, producing automotive components. ISO 27001 certified, but OT (operational technology) environments were excluded from scope.

Challenge: The company's IT environment had basic software controls, but the OT environment (SCADA, PLCs, HMIs, engineering workstations) had no controls. Maintenance engineers shared administrator passwords for engineering workstations. They frequently downloaded PLC programming tools, firmware updates, and HMI configuration software from peer-to-peer networks, vendor forums, and WhatsApp groups. A maintenance engineer at the Gujarat plant downloaded a "free PLC simulator" from a WhatsApp group link. The simulator was a trojan that installed a backdoor and a cryptominer. The cryptominer consumed 80% of the PLC's CPU, causing production line delays and quality defects. The backdoor allowed an attacker to access the plant's SCADA network. The attacker encrypted the SCADA historian database with ransomware, demanding . The company could not determine what software was installed on the 45 engineering workstations because there was no inventory. The incident caused 3 days of production stoppage, affecting just-in-time delivery to a major automotive OEM.

Solution: The company engaged Singahi to extend A.8.19 to OT environments:

1. Phase 1 (Air-gapped inventory): Deployed portable asset discovery tools on air-gapped engineering workstations. Created a manual software inventory for all 45 workstations. Discovered 312 unauthorized software instances, including 67 pirated tools, 18 outdated firmware versions, and 23 unknown executables.
2. Phase 2 (Access control): Implemented unique accounts for each maintenance engineer. Removed shared admin passwords. Deployed jump boxes for remote vendor access. Implemented session recording for all OT remote access.
3. Phase 3 (Software approval): Created an OT-approved software catalog with 28 essential tools. All new software required dual approval (OT manager + CISO). Firmware updates required vendor hash verification and testing on a spare PLC before production deployment.
4. Phase 4 (Network segmentation): Segregated OT networks from IT networks using industrial firewalls (A.8.22). Implemented unidirectional gateways for data transfer from OT to IT.
5. Phase 5 (Monitoring): Deployed OT-specific IDS (Nozomi Networks, Claroty) to monitor for unauthorized software execution and network anomalies. Integrated OT alerts with the IT SIEM (IBM QRadar).

Results:

• Unauthorized OT software: 312 → 0 (within 4 months)
• Shared admin passwords: 45 → 0 (replaced with unique accounts + MFA)
• OT security incidents: 2 per quarter → 0 (ongoing)
• Production downtime due to security: 3 days → 0
• OEM relationship: Preserved. The automotive OEM conducted a security audit and approved the plant for continued supply.
• ISO 27001 scope expansion: Successfully included OT environments in the ISMS scope.
• overhead: for OT security tools, network segmentation, and consulting. ROI: The production stoppage overhead in lost revenue + ransom demand. The total breach overhead was estimated at . The security investment paid for itself 9x in the first year.

Quote from the Plant Manager: "We treated OT as 'not IT' and therefore 'not security.' That was our biggest mistake. Singahi showed us that OT software controls are just as critical as IT controls, maybe more so, because OT failures stop production. The investment in OT security has actually improved our uptime, not hurt it."

Multi-Framework Mapping

Regulatory and Industry Context

Indian Regulatory Requirements

Industry-Specific Context

Banking (RBI):

• Core banking software changes require RBI notification and dual control
• ATM software must be from approved vendors only; no third-party tools
• SWIFT infrastructure requires dedicated software with no unauthorized additions
• UPI and payment gateway software must be certified by NPCI

Healthcare (NABH):

• Medical device software (FDA 21 CFR Part 820 equivalent) requires validation before use
• EMR software must be from CDAC-certified or NABH-approved vendors
• PACS software must be assessed for patient data security
• Telemedicine platforms must comply with Ministry of Health guidelines

Manufacturing (Make in India):

• SCADA and PLC software must be assessed for supply chain security
• IoT firmware must be verified for backdoors (especially Chinese-origin IoT devices)
• Industrial robots and CNC machines must have controlled software environments
• Smart factory initiatives (Industry 4.0) require secure software supply chains

IT/ITeS (STPI/SEZ):

• Client-mandated software security requirements often exceed ISO 27001
• Export control regulations (EAR, ITAR) may restrict software origin
• GDPR compliance for EU clients requires software controls on personal data processing
• Many clients require SBOMs and software supply chain attestations

RACI Matrix

A = Accountable, R = Responsible, C = Consulted, I = Informed

Documentation and Evidence Requirements

Documents Required

1. Software Installation Policy, Approved by management, communicated to all staff
2. Software Installation Procedure, Step-by-step process for requesting, assessing, approving, installing, and verifying software
3. Approved Software Catalog, Curated list of approved software with versions, vendors, and business justifications
4. Software Request Form, Template for requesting new software
5. Software Inventory, Complete inventory of all software on all operational systems
6. Software Baseline, Approved configuration for each system type
7. Change Management Records, All software installation change requests and approvals
8. CAB Meeting Minutes, For normal changes requiring CAB review
9. Security Assessment Reports, Malware scans, vulnerability checks, open source assessments
10. Integrity Verification Records, Hash checks, signature verification logs
11. Software Removal Records, Documentation of unauthorized software detection and removal
12. Incident Records, Any security incidents related to unauthorized software
13. Training Records, Evidence that staff have been trained on the software installation policy
14. Vendor Security Assessments, For third-party and commercial software
15. License Compliance Records, Software license inventory and compliance status
16. EOL Software Tracking, List of end-of-life software with replacement plans
17. SBOMs, Software Bill of Materials for all applications
18. Drift Detection Reports, Regular comparisons of system state against baselines
19. Monitoring Alerts, SIEM/EDR alerts for unauthorized installation attempts
20. Audit Reports, Internal and external audit findings for A.8.19

Evidence Retention

• Policies and procedures: Retain current version + all previous versions for 7 years
• Software inventory: Update monthly; retain historical snapshots for 3 years
• Change records: Retain for 7 years (or as per regulatory requirements)
• Security assessments: Retain for 3 years
• Incident records: Retain for 7 years (or as per regulatory requirements)
• Training records: Retain for 3 years after employee departure
• Audit reports: Retain for 7 years
• SBOMs: Retain for the lifetime of the application + 3 years

Continuous Improvement

Maturity Model for A.8.19

Improvement Roadmap

• From Level 1 to 2: Create basic inventory; remove admin rights from 50% of users; implement informal approval for critical software
• From Level 2 to 3: Complete inventory; formalize approval workflow; remove all admin rights; deploy application control on all systems; integrate with change management
• From Level 3 to 4: Automate inventory discovery; implement real-time monitoring; deploy SCA tools; generate SBOMs for all applications; implement license management
• From Level 4 to 5: Implement AI-powered monitoring; automate unauthorized software remediation; deploy zero-trust application control; integrate with threat intelligence feeds; predictive patch management

Key Improvement Metrics

• Year-over-year reduction in unauthorized software instances
• Year-over-year reduction in open source vulnerabilities
• Year-over-year improvement in patch compliance
• Year-over-year reduction in software-related security incidents
• Year-over-year efficiency gains from license optimization and software rationalization

FAQ

Q1: Does A.8.19 apply to cloud resources? A: Yes. Cloud VMs, containers, serverless functions, and SaaS desktop clients are all operational systems. You must control what software is installed on cloud resources, just as you do on-premise.

Q2: Do we need to restrict software installation on development workstations? A: Yes, but with a different baseline. Developers need more software, but all software should still be approved, inventoried, and assessed. Development environments must be separated from production (A.8.31).

Q3: How do we handle emergency security patches? A: Use an emergency change procedure. Install the patch immediately, document the change retrospectively, and obtain approval within 24 hours. Do not let bureaucracy delay critical security updates.

Q4: What about software installed by vendors or MSPs? A: Vendor-installed software must go through the same approval process. Include software requirements in vendor contracts. Monitor vendor activity with session recording. Require vendors to provide hashes and signatures for all software they install.

Q5: How do we control software on BYOD devices? A: Use MDM/UEM tools to manage corporate data and apps on BYOD devices. Implement app-level policies that restrict installation of unapproved apps. Use containerization (e.g., Microsoft Intune App Protection) to isolate corporate data from personal apps.

Q6: Is open source software inherently risky? A: No, but it requires assessment. Many open source projects are well-maintained and secure. The risk comes from unmaintained projects, vulnerable dependencies, and malicious packages. Use SCA tools, SBOMs, and private registries to manage open source risk.

Q7: How do we handle legacy software that cannot be removed? A: Isolate legacy systems on a separate network segment. Implement compensating controls (network monitoring, strict access controls, application firewalls). Plan for replacement. Document the risk and obtain management acceptance.

Q8: What is the difference between application whitelisting and blacklisting? A: Whitelisting (allowlisting) allows only approved software, everything else is blocked. Blacklisting (blocklisting) blocks known bad software, everything else is allowed. Whitelisting is more secure but requires more maintenance. For critical systems, use whitelisting. For general systems, a combination of both is practical.

Q9: How do we balance security with developer productivity? A: Create a developer-approved software catalog with all essential tools. Use self-service portals for rapid approval of common tools. Implement SCA in CI/CD so developers get immediate feedback on vulnerabilities. Standardize development environments (devcontainers, Docker) to reduce "works on my machine" issues.

Q10: Do we need to inventory firmware? A: Yes, firmware is software embedded in hardware. Firmware vulnerabilities (e.g., BIOS, UEFI, router firmware, IoT firmware) are increasingly exploited. Include firmware in your inventory, track versions, and apply vendor updates through your change management process.

References

1. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information Security Management Systems, Requirements
2. ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection, Information security controls
3. NIST Cybersecurity Framework 2.0, Identify, Protect, Detect, Respond, Recover, Govern
4. CIS Controls v8, Control 2: Software Asset Management and Control 10: Malware Defenses
5. PCI DSS v4.0, Requirements 6.5 and 11.5.2
6. RBI Cyber Security Framework, Software inventory and change management requirements
7. CERT-In Guidelines, Application whitelisting and software inventory for critical infrastructure
8. DPDP Act 2023, Data protection and system security requirements
9. NIST SP 800-53 Rev 5, CM-7 (Least Functionality), CM-8 (System Component Inventory), CM-11 (User-Installed Software), SI-3 (Malicious Code Protection)
10. OWASP Software Component Verification Standard, For open source and third-party software verification
11. NTIA SBOM Minimum Elements, For Software Bill of Materials implementation
12. CISA Known Exploited Vulnerabilities Catalog, For prioritizing patch management

This guide is part of the Singahi ISO 27001:2022 Annex A Control Guide Series.

Contact: security@singahi.com | singahi.com

Industry-Specific Storage Requirements

Different industries in India have unique storage requirements driven by sector-specific regulations, operational criticality, and threat landscapes. Organizations must adapt A.8.19 controls to their industry's specific needs.

Banking and Financial Services (BFSI)

Regulatory Drivers:

• RBI Cyber Security Framework (2016, updated 2024): Mandates data localization, encryption at rest and in transit, and incident reporting within 6 hours
• SEBI Cybersecurity Guidelines (2019): Requires stockbrokers and depositories to maintain immutable audit logs for 7 years
• PCI DSS v4.0: Cardholder data storage restrictions and encryption requirements

Specific Storage Requirements:

BFSI Storage Architecture Example:

Primary DC (Mumbai)
├── Tier 1: Active transactional databases (SSD, replication)
├── Tier 2: Analytics warehouse (hybrid SSD/HDD)
├── Tier 3: Archive (HDD, compressed, encrypted)
└── Tier 4: Immutable audit logs (WORM tape, 7-year retention)

DR Site (Chennai)
├── Synchronous replication for Tier 1 (RPO ≈ 0)
├── Asynchronous replication for Tier 2 (RPO ≤ 15 min)
└── Daily backup sync for Tier 3-4

Air-Gapped Vault (Hyderabad)
└── Monthly offline backups on encrypted tape, 3-year retention

BFSI-Specific Risks:

• Insider Trading Data Leaks: Employees with access to privileged information may exfiltrate data. Implement DLP, strict access controls, and behavior analytics.
• Ransomware Targeting: BFSI is a high-value ransomware target. Maintain offline backups, test recovery quarterly, and implement network segmentation.

Healthcare and Life Sciences

Regulatory Drivers:

• DPDP Act 2023: Digital personal data protection with consent requirements
• Health Data Management Policy (MoHFW, 2020): Health data classification and security requirements
• Indian Medical Council Regulations: Patient record confidentiality
• ISO 27799:2016: Health informatics, Information security management in health

Specific Storage Requirements:

Healthcare Storage Architecture Example:

Hospital Network
├── HIS (Hospital Information System): Patient demographics, billing, appointments
├── EMR/EHR: Clinical notes, prescriptions, lab results
├── PACS: DICOM images (X-ray, CT, MRI) — 50TB+ per large hospital
├── LIS: Lab Information System — test results, instrument data
├── RIS: Radiology Information System — radiology workflow
└── Research Repository: Anonymized datasets for clinical trials

Cloud Integration
├── Tier 1: Hot patient data (active admissions) — On-premise SSD
├── Tier 2: Warm patient data (recent discharges) — Hybrid cloud
├── Tier 3: Cold archives (old records) — Cloud archive storage
└── Disaster Recovery: Cross-region cloud replication

Healthcare-Specific Risks:

• Ransomware on Hospitals: In 2021, AIIMS Delhi suffered a ransomware attack affecting 5 servers with 1.3TB of data. Offline backups and rapid recovery are critical.
• Medical Device Data: IoT medical devices (MRI, CT scanners, infusion pumps) generate data that must be stored securely. Many devices run outdated OS with no patching support.
• Third-Party Cloud Risks: Healthcare providers using cloud EMR systems (e.g., Practo, Lybrate) must ensure data residency and BAA (Business Associate Agreement) compliance.

Government and Public Sector

Regulatory Drivers:

• IT Act 2000 (as amended): Section 43A, compensation for failure to protect data
• CERT-In Directions (2022): Mandatory reporting of cybersecurity incidents, data localization for government data
• National Data Governance Framework (2023): Data classification and sharing guidelines
• GeM (Government e-Marketplace) Security Requirements: Secure storage of procurement data

Specific Storage Requirements:

Government Storage Architecture Example:

 classified Network (Air-Gapped)
├── SCADA Systems: Critical infrastructure control
├── Defense Systems: Military operational data
├── Election Systems: EVM management, voter rolls
└── Census Data: Demographic information

Government Intranet
├── e-Office Files: Administrative documents
├── GSTN Data: Tax records (5-year retention)
├── Passport/Visa Data: Immigration records (25-year retention)
└── Land Records: Property registration (permanent retention)

Public Cloud (MeghRaj Approved)
├── Public datasets: Open data portals
├── Non-sensitive applications: Citizen portals
└── Development/test environments

Government-Specific Risks:

• Nation-State APTs: Indian government systems are targets for APT groups (e.g., APT32, APT36). Air-gapping and strict access controls are essential.
• Insider Threats: Government employees with privileged access may leak data for monetary or political gain. Implement strict need-to-know access and continuous monitoring.
• Legacy System Vulnerabilities: Many government systems run on outdated platforms (Windows XP, old Unix systems) with no vendor support. Plan for migration or implement compensating controls.

IT/ITeS and SaaS Companies

Regulatory Drivers:

• DPDP Act 2023: Data fiduciary obligations for SaaS companies processing Indian user data
• SEBI LODR (for listed IT companies): Data governance and disclosure requirements
• MeitY Guidelines for SaaS: Data localization and security requirements for government SaaS procurement

Specific Storage Requirements:

IT/ITeS Storage Architecture Example:

SaaS Platform
├── Application Layer: Microservices, containerized
├── Data Layer: Sharded databases per tenant region
├── Object Storage: Files, images, documents (S3-compatible)
├── Cache Layer: Redis/Memcached for hot data
├── Search Index: Elasticsearch for full-text search
└── Analytics: Data warehouse for platform analytics

Regional Deployment
├── India Region: Primary for Indian customers
├── EU Region: GDPR-compliant for European customers
├── US Region: For North American customers
└── Cross-Region Replication: Disaster recovery only

Manufacturing and Industrial

Specific Storage Requirements:

• OT/IT Convergence: Manufacturing execution systems (MES) must bridge operational technology (OT) and IT storage with secure gateways.
• IoT Data Volume: Industrial IoT sensors generate massive data volumes (terabytes per day). Implement edge computing with tiered storage.
• Intellectual Property Protection: CAD files, product designs, and manufacturing processes are critical IP. Store in encrypted vaults with DLP.
• Supply Chain Data: Vendor quality data, inspection reports, and compliance certificates must be retained for product lifecycle + 10 years.

Retail and E-Commerce

Specific Storage Requirements:

• Customer Payment Data: PCI DSS compliance, no storage of CVV, encrypt PAN, tokenize where possible.
• Personalization Data: Customer browsing history, preferences, and purchase data, comply with DPDP Act consent requirements.
• Inventory Data: Real-time inventory synchronization across warehouses, stores, and online platforms.
• Seasonal Scaling: Storage must scale 10x during festive seasons (Diwali, Big Billion Day). Use cloud auto-scaling.

Q11: How does data sovereignty affect cloud storage decisions? A: Data sovereignty laws (DPDP Act 2023, CERT-In directions) require certain data to remain within India. When selecting cloud providers, verify they have Indian data centers (AWS Mumbai, Azure Pune, GCP Delhi). Use region locks to prevent data replication outside India. For highly sensitive data, consider private cloud or on-premise storage with Indian ownership.

Q12: What is the difference between hot, warm, and cold storage? A: Hot storage is for frequently accessed data with low latency requirements (SSD, premium cloud storage). Warm storage is for occasionally accessed data with moderate latency (standard HDD, standard cloud storage). Cold storage is for rarely accessed archival data with high latency tolerance (tape, archive cloud storage, glacier). The overhead decreases from hot to cold, while retrieval time increases.

Q13: How do we handle storage for AI/ML training datasets? A: AI/ML datasets require massive storage (petabytes for large models). Use object storage (S3, MinIO) for raw data, high-performance storage (NVMe, parallel file systems) for training workloads, and version control (DVC, Git LFS) for dataset versioning. Ensure training data containing PII is anonymized or used with appropriate consent under DPDP Act 2023.

Q14: What storage considerations apply to blockchain and distributed ledger systems? A: Blockchain storage is append-only and immutable by design. Each node maintains a full copy, creating data redundancy. For Indian organizations using blockchain (e.g., for supply chain, land records), ensure nodes are hosted within India, consensus mechanisms don't leak sensitive data, and private/permissioned blockchains are used for confidential data. Plan for exponential storage growth as chains grow indefinitely.

Q15: How do we manage storage for video surveillance systems? A: CCTV and video surveillance generate massive storage demands (1TB per camera per month for 4K). Use motion-based recording to reduce storage. Retain footage per regulatory requirements (typically 30-90 days for general, longer for critical areas). Encrypt stored footage. Implement automatic deletion after retention period. For government installations, follow MeitY guidelines on video surveillance data handling.

This guide is part of the Singahi ISO 27001:2022 Annex A Control Guide Series.

Contact: security@singahi.com | singahi.com