Episode 17 — Safeguard 3.3 – Data encryption at rest and in transit

Safeguard 3.3 requires organizations to protect sensitive data through encryption, both when stored (at rest) and when moving across networks (in transit). Encryption transforms readable information into an unreadable form using cryptographic algorithms, ensuring that even if data is intercepted or stolen, it cannot be easily exploited. Encrypting data at rest protects information stored on servers, databases, laptops, or removable media from unauthorized access or loss. Encrypting data in transit safeguards it as it travels between systems, applications, and users—whether through email, APIs, or file transfers. Together, these measures uphold the confidentiality and integrity of information, a fundamental principle within cybersecurity frameworks. Modern encryption standards such as AES-256 for storage and TLS 1.3 for transmission are now baseline expectations for regulatory compliance across industries.

Effective encryption strategies extend beyond turning on a feature—they involve key management, configuration, and verification. Enterprises must use centrally managed key management systems (KMS) to control how cryptographic keys are generated, stored, rotated, and retired. Poor key management can undermine even the strongest algorithms. Encryption coverage must include portable devices and backups, since lost laptops or misconfigured cloud storage buckets are frequent sources of data breaches. Organizations should also ensure that encryption is transparent to legitimate users but impenetrable to unauthorized actors, balancing usability with protection. Regular audits of encryption settings and periodic penetration tests confirm effectiveness. As cyber threats evolve, encryption remains one of the most resilient and adaptable defenses, converting sensitive data from a high-value target into a controlled, inaccessible asset.
 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 17, Control 2 (00:00):
Approval, Allowlisting, and Updates, where we explore the mechanisms that keep your software environment both secure and stable. Discovery gives you visibility, but approval and allowlisting give you authority—ensuring that only trusted, necessary, and verified software runs within your enterprise. This control moves from observation to enforcement, linking governance decisions directly to operational safeguards. In this episode, we will walk through how to establish approval governance, maintain your allowlist and deny list, manage updates safely, and create metrics that prove your program remains current and compliant.

(00:39):
Governance roles and responsibilities define how these approvals occur and who enforces them. Typically, the security or compliance team owns the approval policy, while IT administrators handle technical enforcement. Business units may submit requests for new software, and risk managers assess impact before approval. The process should specify reviewers, escalation paths, and timelines to avoid bottlenecks. Clear separation of duties ensures transparency—no one should both request and approve the same application. Governance structure transforms software management from ad hoc decision-making into an auditable workflow that balances agility with oversight.

(01:21):
Creating the approved software catalog begins with your discovery data. From that inventory, identify all applications that meet licensing, security, and operational standards. Record each by name, version, publisher, and business purpose. Assign ownership to maintain currency and document any dependencies or installation paths. This catalog becomes the reference point for configuration management, patching, and endpoint protection. Ideally, it lives in a centralized system accessible to administrators and auditors alike. Updates to the catalog follow controlled change processes, ensuring that approvals remain deliberate and traceable rather than reactive.

(02:01):
The deny list, sometimes called a blocklist, complements the approved catalog by defining prohibited categories and specific applications. Common examples include peer-to-peer file sharing, unlicensed software, or unsupported browsers. Deny lists may also include tools known to bypass controls or create data privacy risks. Automated systems can scan for these programs and either remove them or restrict their execution. Maintaining deny lists requires vigilance—software evolves quickly, and a once-benign tool can become risky through version changes or ownership shifts. Periodic review ensures the deny list reflects current threats and policies.

(02:43):
Installer control policies govern how and by whom software is installed. Only authorized administrators or automated deployment systems should have installation rights. Enforcement can occur through endpoint management tools, group policies, or local privilege management. Policies should specify approved installation methods, prohibited directories, and validation steps such as signature checking before execution. Combined with monitoring, these controls prevent users from introducing unapproved or outdated programs. Over time, installer restrictions become the front line of defense against unauthorized software, ensuring consistency across all managed systems.

(03:24):
Application control technologies implement allowlisting, deny listing, or audit modes. In allow mode, only approved software executes; deny mode blocks known unwanted programs; and audit mode records activity without enforcement, useful for testing policies before deployment. Many organizations start in audit mode to observe behavior and tune rules, then gradually enforce stricter controls. Balancing usability with security is critical—overly restrictive policies can hinder legitimate work. A phased approach helps teams understand how policies affect daily operations while still reducing risk.

(04:02):
Exception requests are the built-in flexibility that keeps governance practical. Certain applications may be necessary but not fully compliant—perhaps they lack a digital signature or run only on outdated frameworks. The exception process requires a documented justification, compensating controls, and an expiration date. Approvals should route through security and management reviewers, and exceptions should be revisited regularly. This method keeps the allowlist trustworthy while accommodating legitimate business needs. It also prevents exceptions from becoming permanent loopholes by requiring periodic reevaluation.

(04:40):
Update channels, trusted sources, and scheduling define how approved software remains current. Update channels—whether vendor-hosted, on-premises repositories, or automated patch systems—must be clearly documented and restricted to trusted origins. Scheduling updates according to defined cadences—monthly, quarterly, or critical-only—ensures predictable maintenance without overwhelming teams. Automatic updates should be monitored for verification, while manual updates should follow the same integrity checks as initial installations. Regular updates maintain currency, a key indicator for auditors assessing how well you manage vulnerabilities through timely patching.

(05:21):
Ringed testing and phased rollout strategies provide safe deployment for updates. The idea is to apply updates first to a small, representative group of systems before wider release. This allows detection of conflicts or performance issues early, protecting production environments from disruption. Rings can include test, pilot, and general availability phases. Each ring must have defined exit criteria, such as successful testing or incident-free operation for a set period. Phased rollouts build trust between IT, security, and end users by demonstrating that updates are deliberate, measured, and reversible.

(06:00):
Rollback plans and recovery steps prepare you for the times when updates go wrong. Even well-tested patches can introduce issues. A rollback plan defines how to revert systems to the previous stable version, whether through snapshots, backups, or uninstallation scripts. Recovery steps outline who executes the rollback, how communication occurs, and what validation confirms restoration. Including rollback procedures in your governance plan demonstrates maturity and risk awareness. It shows that your organization can act decisively without compromising stability or security during recovery.

(06:35):
Recordkeeping, approvals, and attestations form the evidence trail of your software control system. Every approval, denial, or exception must be documented, along with who authorized it and when. Logs from application control systems and installer tools record enforcement actions. Attestations—signed confirmations from system owners—validate that endpoints comply with allowlist policies and update schedules. These records not only satisfy auditors but also support internal reviews by providing a factual basis for decisions. A clean, traceable record demonstrates control integrity and operational accountability.

(07:15):
Metrics for this control focus on coverage, currency, and exceptions. Coverage measures how many systems enforce allowlisting or have approved software installed. Currency tracks the percentage of applications updated within policy-defined timeframes. Exceptions quantify how many temporary deviations exist and how long they persist. Monitoring these metrics helps identify where governance is slipping—perhaps too many exceptions or delayed updates. Consistent reporting ensures that leadership sees progress and understands where attention or resources are needed.

(07:51):
Approval, allowlisting, and update management transform software control from static documentation into active defense. They create a verifiable chain of trust—from acquisition to installation to maintenance. When software is properly vetted, installed, updated, and logged, you minimize vulnerabilities and operational chaos. As you move into the next episode, we will explore software lifecycle governance—how to manage ownership, decommission outdated applications, and maintain accuracy over time—ensuring that every program in your environment continues to serve a valid, secure, and well-documented purpose.