Episode 15 — Safeguard 3.1 – Data classification and inventory

Safeguard 3.1 instructs organizations to establish and maintain a structured data management process, beginning with classification and inventory. This process determines what data exists, where it resides, who owns it, and how sensitive it is. Classification typically categorizes information as public, internal, confidential, or restricted, though labels may vary depending on industry or regulation. The goal is to assign clear handling requirements and protection levels to each category. By doing so, enterprises can focus resources on securing their most valuable or regulated data instead of applying uniform—but inefficient—controls across all assets. Creating a data inventory complements this classification by mapping repositories, databases, file systems, and applications that store or process sensitive information. Together, these steps provide visibility and accountability, forming the foundation for subsequent safeguards like access control, encryption, and retention management.

Implementing this safeguard requires collaboration between security teams, data owners, and business units. Automation tools such as data discovery scanners, metadata analysis platforms, and cloud governance utilities help identify sensitive data across diverse storage locations, including on-premises servers, SaaS applications, and portable devices. Regular reviews ensure that classifications remain accurate as data changes or new systems are introduced. The inventory should also track the lifecycle of each dataset—from creation and active use to archival and disposal—enabling precise enforcement of retention and deletion policies. Establishing ownership for each data category ensures someone is accountable for maintaining compliance and responding to incidents involving that data type. Over time, the organization gains not only better protection but also operational insight: knowing what data exists simplifies audits, accelerates incident response, and improves decision-making about where to store or share information. Safeguard 3.1 therefore bridges governance and technology, turning abstract privacy obligations into tangible, measurable actions that protect the enterprise’s informational core.
 Produced by BareMetalCyber.com, where you’ll find more cyber audio courses, books, and information to strengthen your educational path. Also, if you want to stay up to date with the latest news, visit DailyCyber.News for a newsletter you can use, and a daily podcast you can commute with.

Episode Transcript

Welcome to Episode 15, Control 2 (00:00):
Overview and Outcomes, where we shift our focus from physical and virtual hardware to the software running on it. Control 2, Inventory and Control of Software Assets, builds directly on the foundation of Control 1. If the first control ensures you know what devices exist, this control ensures you know what those devices are running. In today’s environments—where applications, containers, and scripts can appear and disappear within minutes—software visibility is as important as device visibility. This episode explains what the control covers, what it aims to achieve, and how to manage the software lifecycle in a way that supports both security and operational integrity.

(00:42):
The purpose of software asset control is to prevent unauthorized or vulnerable programs from operating within your environment. Every installed application, component, or library represents potential risk if it is outdated, unapproved, or malicious. Attackers often exploit weaknesses in unmanaged software or rely on users installing unsafe tools. By maintaining a complete inventory of what software is allowed and ensuring it stays current, you reduce exposure dramatically. This control also helps with compliance and licensing, making it easier to prove that your organization uses only authorized products. Its goal is to achieve predictable, trustworthy computing—where every executable is known, approved, and maintained.

(01:28):
The scope of this control includes both operating systems and applications, whether they are commercial, open source, or internally developed. Operating systems form the base layer and must be tracked by version and patch level. Applications include everything from productivity suites to databases, browsers, and client tools. Server software, middleware, and command-line utilities all count as software assets. To stay compliant with CIS expectations, your inventory should capture both what is installed and where it resides. Coverage should extend across desktops, servers, virtual machines, and cloud-hosted workloads. The goal is to know exactly which versions are active and which require updates or removal.

(02:13):
Software asset management extends beyond traditional applications to include packages, scripts, extensions, and background services. Modern systems run hundreds of small components that may not appear in standard installers—browser plug-ins, Python packages, Node modules, or automation scripts. These lightweight elements can still introduce vulnerabilities or violate policy. A comprehensive approach includes cataloging them through discovery tools, developer registries, or code repositories. Even small automation scripts should be identified and reviewed if they run on production systems. Recognizing that “software” means every executable instruction, not just commercial products, helps prevent oversight in your security program.

(02:57):
Cloud images, containers, and serverless functions expand the meaning of software inventory. Each image or container is essentially a software package, containing its own stack of dependencies. Serverless platforms host code that executes on demand, often outside traditional monitoring. These assets must be inventoried through integration with cloud APIs or orchestration systems. Include image names, registry locations, and version tags. Tracking these ephemeral components ensures that your inventory reflects modern architectures rather than only legacy endpoints. When your control includes these elements, you gain full visibility into every layer of execution, no matter where it runs.

(03:38):
The primary objectives of this control are accuracy, approval, and currency. Accuracy means every piece of software in use is correctly recorded with its name, version, and installation path. Approval means it has been vetted for business need, licensing, and security compliance. Currency means it is up to date with the latest patches and supported by the vendor. Together, these objectives create a cycle of control—software is identified, authorized, maintained, and retired. This ensures that your organization operates only on trusted code and that vulnerabilities are patched before attackers can exploit them.

(04:18):
An approved list and a deny list bring structure to this control. The approved list defines what software and versions are authorized for use, often categorized by business unit or function. The deny list identifies prohibited or high-risk software, such as outdated browsers or unlicensed tools. Automated tools can enforce these lists by blocking or alerting when unapproved software appears. Maintaining these lists requires collaboration between security, IT, and business owners. Over time, they become central to governance, helping teams make consistent, risk-informed decisions about new tools or updates.

(04:56):
To maintain meaningful records, your inventory must include version, publisher, and license fields for each entry. Version numbers confirm patch status and compatibility. Publisher information validates source authenticity and helps track vendor advisories. License data ensures legal compliance and budget accuracy. Including these fields in your software asset inventory allows quick analysis—such as identifying which systems are running outdated versions or nearing license expiration. Structured, complete metadata turns your inventory from a static list into a management system that supports both compliance and operational planning.

(05:36):
Update channels and patch cadence are how you keep authorized software current. Each product should have a defined update mechanism—manual patching, automated updates, or centralized distribution. Your cadence depends on business tolerance for change and risk exposure. Critical systems may patch monthly, while high-risk endpoints update more frequently. Documenting and adhering to these schedules demonstrates maturity. Metrics showing timely patching also serve as key indicators for Control 7, Continuous Vulnerability Management, linking software control directly to ongoing risk reduction.

(06:09):
Installer control and execution policy address how software enters your environment. Restrict installation privileges to authorized administrators or automated deployment systems. Use application allowlisting, where only approved executables may run, or require digital signatures for all installations. Script execution policies can limit which directories or users can run code. These measures ensure that the software environment remains stable and predictable, minimizing the chance of users introducing untested or unsafe applications. Combined with monitoring, installer control keeps your software ecosystem trustworthy and traceable.

(06:48):
Metrics for Control 2 focus on coverage, currency, and exceptions. Coverage measures what percentage of systems have their software fully inventoried. Currency measures how many installed applications are updated within defined patch timelines. Exceptions track any deviations from policy, such as unsupported but necessary software. Tracking these three metrics helps gauge control performance and guides resource allocation. Over time, trends in these numbers reveal whether governance is improving or if technical debt is accumulating. Reporting them in dashboards reinforces transparency and accountability across teams.

Common pitfalls include incomplete inventories, outdated entries, and unclear ownership. Many organizations struggle with tracking software on remote or cloud-based systems, leading to blind spots. Others fail to maintain their approved lists, allowing unvetted tools to persist. Practical fixes start with automation (07:27):
integrate discovery tools with your inventory platform, enforce policy through allowlisting, and schedule regular reconciliation. Assign owners for key software categories so responsibility is shared. These simple steps prevent drift and ensure that the control remains sustainable over time.

(08:05):
Software asset control closes the loop between hardware visibility and vulnerability management. It ensures that every program running in your environment is known, approved, and current. By maintaining accurate inventories, enforcing approval lists, and monitoring updates, you create a stable base for security and compliance across the enterprise. As we move forward, the next episode will explore discovery methods for software assets—how to detect what is installed, compare results across tools, and ensure your software inventory remains as complete and dependable as your hardware inventory.