We’ve all been there or at least seen some version of it. An organization or federal agency identifies a requirement or gap and buys a shiny new tool with all the bells and whistles. The solution is designed to meet or exceed a specific need. There’s excitement, momentum, and a clear sense that this new capability will improve things, even if that excitement is mostly limited to the team implementing or using the technology.
For those who advocated for the investment, the purchase feels like a meaningful step forward. Maybe the goal is to improve security, support compliance and governance, enhance visibility and decision-making, increase efficiency, enable growth, or some combination of these. Whatever the driver, the tool’s promised capability is real.
And then…the technology just sits there.
Sure, the solution may be deployed internally, handed off to operations, and added to the organization’s infrastructure or security toolset. But deployment is not the same as implementation. Without the right configuration, hardening, monitoring, testing, and oversight, the tool may never function as intended. Worse, it can create a false sense of security: the organization believes it has addressed a gap, while the underlying risk remains.
When “Enabled” Isn’t Enough
In today’s threat landscape, it’s not enough to set it and forget it. Technology is only as effective as it’s configured, documented, communicated, and monitored over time. Otherwise, it risks becoming another underutilized tool that looks like progress but fails to deliver the protection it was purchased to provide.
Let’s take multi-factor authentication (MFA) as an example. On paper, MFA looks simple: it’s either enabled, or it’s not. But the better question is where and how you enforce it.
Does MFA apply to remote access, privileged accounts, local administrative access, and newly added applications? Are trusted devices, conditional access rules, legacy systems, or other exceptions creating ways around it? Are those exceptions approved, documented, and periodically reviewed? How are service accounts protected? Can the organization demonstrate, through current configurations, testing, and authentication logs, that MFA is enforced across the intended access paths?
The point is not to go down a rabbit hole on MFA. Rather, it’s to show how quickly a “yes, we have that” answer can fall short. Security leaders need to look beyond whether a tool exists and ask whether it’s owned, applied consistently, monitored over time, and producing the outcome it was selected to deliver.
In application security, the Open Worldwide Application Security Project (OWASP) moved Security Misconfiguration from fifth in its 2021 Top 10 to second in its 2025 edition. At the enterprise level, the National Security Agency (NSA) and Cybersecurity and Infrastructure Security Agency (CISA) have identified similar weaknesses. These include default configurations, improper separation of user and administrator privileges, insufficient monitoring, and weak or misconfigured MFA. This illustrates that technology can be present while the intended protection is not.
Verizon’s 2026 Data Breach Investigations Report solidifies the issue. In its analysis of third-party cloud exposures, only 23% of affected third-party organizations fully remediated missing or improperly secured MFA on their cloud accounts. For weak passwords and permission misconfigurations, it took almost eight months to resolve half of the identified findings.
That is the implementation gap in measurable terms. Identifying a weakness and having the capability to address it are important steps, but neither means the exposure has been fully resolved across the environment.
Implementation Requires More Than Technology
The People, Process, Technology framework, sometimes called the Golden Triangle, has been around for decades for a reason. Maybe it’s the consultant and project manager in me, but I still find this framework especially useful when discussing security implementation. A tool may provide the technical capability, but people and processes determine whether and how that capability is used, maintained, and whether it produces the intended outcome.
In practice, implementation gaps tend to show up across all three dimensions. For example:
People
- A new tool or process is rolled out, but users aren’t trained on what changed, why it matters, or their role in security.
- Responsibility is outsourced to a managed service provider (MSP), but internal ownership for oversight, maintenance, and follow-through is never clearly assigned.
Process
- A policy is drafted and approved, but the actual operating process does not reflect what the policy says.
- Exceptions are allowed for business reasons, but they are not tracked, approved, revisited, or formally accepted as risk.
Technology
- A tool is purchased and deployed, but default settings are never adjusted to fit the organization’s environment, workflows, or risk.
- Logs are turned on, but they are not centralized, reviewed, correlated, retained, or used to support detection and investigation.
An organization can have the right tool, policy, and provider and yet still lack the intended protection if those pieces don’t work together post-implementation.
Adopt an Auditor Mindset
One way to close the implementation gap is to think like an auditor. And while I’m absolutely not suggesting all security leaders become auditors, it is possible to shift the mindset from “Do we have this?” to “Can we demonstrate how this is working?”
In other words: show me.
If a tool or security control is truly implemented, the organization should be able to explain how it works, where it applies, who owns it, and how it’s sustained over time. This goes beyond a single policy, screenshot, or verbal confirmation. Those may be part of the story, but they are rarely the whole story.
Put more directly: Are we doing what we say we are doing? If so, how do we know? And how do we improve?
Security leaders can start by asking practical questions of internal teams and service providers throughout implementation and ongoing operations:
- What outcome is this technology intended to produce?
Start with the risk you’re reducing, not the product you’re deploying. - Where is it supposed to apply?
Identify the relevant users, accounts, assets, applications, locations, systems, and access paths. - Is it consistently configured and enforced?
Look for gaps created by exceptions, trusted devices, legacy systems, remote access paths, administrators, service accounts, or third parties. - Who owns its ongoing operation?
Be clear about who monitors failures, reviews exceptions, maintains configurations, retains evidence, and addresses findings. - What happens when the control fails?
Define alerts, escalation paths, remediation expectations, compensating safeguards, and decision points before an incident occurs. - How do we know it works?
Use configuration reviews, sampling, technical testing, operational evidence, interviews, and monitoring data rather than relying solely on policies, screenshots, or status updates.
This mindset is useful whether an organization is preparing for a formal security assessment, working with an MSP, launching a new tool, or simply trying to understand whether its security program is operating as intended. This isn’t about creating evidence for the sake of it. It’s about giving leaders enough visibility and accountability to know whether their controls are actually delivering the protection they expect.
A CMMC Example: Implementation vs. Verification
Implementation, verification, and ongoing sustainment are three different things, and that distinction became clear in July 2026, when the Department of War suspended Cybersecurity Maturity Model Certification (CMMC) Phase II requirements for defense contractors. The conversation was everywhere, mostly about what it meant for the future of third-party assessments. Some organizations treated the pause as a reason to slow down, whereas practitioners were quicker to point out what didn’t change: the obligation to protect Controlled Unclassified Information (CUI) never went away.
CMMC didn’t create the responsibility to protect CUI. For many defense contractors, that obligation already existed through contracts incorporating Defense Federal Acquisition Regulation Supplement (DFARS) clause 252.204-7012, which requires applicable covered contractor systems to implement National Institute of Standards and Technology Special Publication 800-171 (NIST SP 800-171). CMMC provides a mechanism for the Department to verify implementation; however, it is not the source of the security obligation itself.
The same distinction applies to cost. Implementation costs, assessment costs, and ongoing operational costs differ. Implementing and sustaining security requirements may involve technology, configuration, documentation, training, testing, monitoring, ownership, and recurring maintenance. An assessment evaluates whether that implementation exists and operates as required at a point in time. The cost of building and sustaining a security program should not be confused with the cost of verification.
From Deployment to Sustainment
Deployment is not the finish line – the line is constantly moving. Purchasing a tool, approving a policy, closing a ticket, or handing responsibility to a service provider may represent meaningful progress, but none of these prove the intended protection is working across the operational environment.
Once a capability is deployed, it must become part of ongoing operations. Ownership must be clear, configurations must be maintained, exceptions must be managed, and performance must be monitored and periodically tested. This applies to both traditional security technologies and emerging AI-enabled capabilities. Neither will continue producing the intended outcome without ongoing oversight and tuning.
Why? Because environments are not static. New users, systems, applications, integrations, exceptions, and business needs can introduce configuration drift over time. A technology or control that worked as intended on Day 1 can quietly stop working if no one monitors, tests, and maintains it.
For security leaders, the takeaway is simple: measure outcomes, not activity. Know what each control is meant to accomplish, where it applies, who owns it, and how failures are detected and addressed. The strength of an organization’s security posture depends on whether those controls keep working as its systems, operations, and threats evolve.
Sources:
OWASP. (2025). Top 10:2025 – A02:2025 Security Misconfiguration. https://owasp.org/Top10/2025/A02_2025-Security_Misconfiguration/
National Security Agency & Cybersecurity and Infrastructure Security Agency. (2023, October). NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-278a
Verizon. (2026). 2026 Data Breach Investigations Report. https://www.verizon.com/business/resources/T1ae/reports/2026-dbir-data-breach-investigations-report.pdf
U.S. Department of War. (2026, July). Forging the Arsenal of Freedom: Department of War Suspends CMMC Phase II Requirements. https://www.war.gov/News/Releases/Release/Article/4542329/forging-the-arsenal-of-freedom-department-of-war-suspends-cmmc-phase-ii-require/
