Rethink Cybersecurity Awareness Month: 4 different approaches

Cybersecurity Awareness Month shouldn't be measured by how much training employees complete. For executives, its value is greatest when October becomes a catalyst for specific actions that reduce risk, simplify security operations and assign accountability.

The familiar Cybersecurity Awareness Month playbook includes mandatory training, phishing simulations, newsletters, policy reminders and other communications. Reframe awareness as an organizational action for greater impact.

Awareness is more valuable when it changes the organization's actual security and risk posture. I repeat: Don't measure October by how much training people complete. Measure it by what becomes safer. Here are four approaches for doing just that:

1. Four executive fixes in four weeks.
2. One day returned to the security team.
3. A "delete day."
4. One security action for every employee.

Together, these approaches ask a larger question: What could an organization remove, fix, test or improve in October that would leave it measurably safer on November 1?

Four weeks, four cybersecurity fixes: An executive challenge

Instead of treating cybersecurity awareness as an employee training exercise, consider building knowledge with existing processes. Here are four exercises -- one per week -- to start with.

Week 1: Identify the organization's most valuable digital asset

Ask leadership to identify the asset, system, data set or capability whose compromise would create the biggest business impact. This might not be the organization's largest database or most expensive system.

Ask business leaders to consider the exercise in the context of business continuity, revenue, intellectual property, customer trust and regulatory exposure.

From there, the executive question is: Is the organization's highest-value asset receiving appropriate protection and recovery priority?

Week 2: Eliminate one unnecessary privilege

Select and remove one excessive, dormant, shared or otherwise unnecessary privilege. Examples include former administrator access, excessive cloud permissions or standing privileged access. This is a practical application of the principle of least privilege.

Week 3: Test a critical recovery process

Prove the recoverability of one critical process, application or workload. Examples include the following:

• Critical on-premises or cloud application restoration.
• Identity recovery for critical accounts.
• Ransomware recovery.
• Disaster-recovery failover for critical services.

The exercise should prove actual recovery time, dependencies, gaps and decision-making authority. A documented recovery procedure isn't evidence that a recovery will work.

Week 4: Review one cyber-risk metric with leadership

Replace dashboards containing activity metrics with one decision-relevant measure. Activity doesn't demonstrate security. Instead, ask what decision a given metric would empower leadership to make. Here are some potential metrics to track:

• Critical vulnerabilities beyond a remediation service-level agreement.
• Privileged accounts.
• MFA coverage.
• Recovery test performance.
• Unresolved high-impact risks.

Why this works

These four actions create executive participation without requiring them to become security practitioners. The goal is practical: Identify one key business resource, remove one risk, validate one capability and improve one decision. Scope each activity so it can be completed in roughly one week.

Give your security team one day back

This security subtraction exercise is based on one counterintuitive principle: Cybersecurity can improve when organizations stop doing things. Find one security activity that consumes meaningful time but produces little or no risk reduction -- and stop doing it.

Possible candidates include the following:

• Redundant security tooling.
• Reports no one reviews or uses.
• Duplicate alerts.
• Obsolete policies.
• Manual control checks that can be automated.
• Repetitive compliance exercises.
• Unnecessary approval workflows.

Security complexity creates a business problem because more tools and processes > more configuration and integration > more operational burden > more failure opportunities > less attention available for consequential risks.

Tool removal isn't automatically risk reduction; only retire a control after understanding the risk it addresses and whether another control provides equivalent coverage. Security architecture, contractual requirements, regulatory obligations and audit requirements might constrain the removal of tools or policies.

Use three questions to guide the subtraction exercise:

1. What risk does this activity mitigate?
2. How do we know it works?
3. What happens if we stop doing it?

The objective isn't to "do less security," but to concentrate effort where it reduces risk the most. Dedicate reclaimed time to higher-value tasks such as automation, remediation, architecture, recovery testing and threat detection.

Set an annual 'delete day'

Take the idea of security subtraction from the process level to the organization's digital environment. This isn't digital housekeeping; if an asset no longer has a legitimate business purpose, eliminating it removes the need to secure, monitor, patch, authenticate or govern it.

Use the following four stages to establish the risk management concept and set it as an annual activity.

1. Define the ritual

Create an annual October event in which teams deliberately identify and remove digital assets that no longer have a legitimate business purpose. Potential targets include dormant accounts, unnecessary administrative privileges, unused applications, forgotten or orphaned cloud resources, obsolete API keys, stale vendor access, abandoned data and unused service accounts.

2. Make attack-surface reduction the objective

The goal is to remove every unnecessary account or exposed resource that can create another pathway to compromise. It's usually better to remove a resource than to add another monitoring rule around it. Attack surface reduction is typically more effective than remediation because it eliminates an asset or access path rather than just making it safer.

Attack surface removal candidates include identity directories, cloud subscriptions or resources, SaaS applications, API credentials and third-party connections. Search for shadow IT environments, too.

3. Guardrails before deletion

Before removing assets, teams must establish these criteria:

• Ownership.
• Business purpose.
• Data-retention requirements.
• Legal and regulatory obligations.
• Evidence that the asset is genuinely unused.

Establishing a rollback or recovery procedure is crucial. An apparently dormant resource can have an undocumented dependency.

4. Measure what disappeared

Generate accurate evidence of attack surface reduction, not participation metrics. Track the following:

• Accounts removed.
• Privileged accounts removed.
• Applications retired.
• Cloud resources decommissioned.
• Credentials revoked.
• Third-party access removed.
• Data sets securely disposed of.

The difference is that standard Cybersecurity Awareness Month training might indicate 96% of employees completed awareness training. A stronger business outcome is 184 dormant accounts removed, 12 abandoned cloud resources eliminated and one crucial recovery process successfully tested.

Make October the month of 'one thing'

Build a role-based program around a single principle: One person. One action. One measurable improvement.

Use the following role assignments as a springboard:

• CEO and executives: Review privileged access.
• Developer: Remove an insecure dependency.
• IT: Close dormant accounts.
• Procurement: Review a critical supplier's security requirements and access.
• Employee: Enable phishing-resistant MFA.
• Security: Automate one manual control.
• Infrastructure: Remove one unused cloud resource.

Each action should be role-specific, not generic or across-the-board activities. For every role assignment, define the owner, action, deadline, evidence of completion, and risk reduction or operational outcome.

Prepare documentation, instructions or procedures for each role activity. Make each task relevant to the assigned role. Universal tasks are easier to administer but might be irrelevant to many roles. Individualized tasks are more impactful but require coordination. Security should build a framework with role-specific actions and guardrails.

Capture completed improvements in existing risk-management, identity and access management, vulnerability-management, asset-management or governance workflows.

Use October's Cybersecurity Awareness Month as a catalyst for momentum, not a finish line. Continue the initiative once metrics prove its effectiveness.

Conclusion: October should leave the organization safer than it found it

Instead of mandating phishing detection or strong password training for every employee, use Cybersecurity Awareness Month to drive real change. Use the above four approaches to complete specific activities:

• Fix something.
• Stop something.
• Delete something.
• Assign one meaningful improvement to everyone.

Instead of training for vague practices, let cybersecurity awareness permeate security activities and outcomes. At the next leadership meeting, ask each security or technology leader, "What is one thing we can remove, fix, test or improve this October?"

Damon Garn owns Cogspinner Coaction and provides freelance IT writing and editing services. He has written multiple CompTIA study guides, including the Linux+, Cloud Essentials+ and Server+ guides, and contributes extensively to Informa TechTarget, The New Stack and CompTIA Blogs.