Cybersecurity Compliance Has to Outlast the People and Systems Behind It

SteelCloud advisor Mike Korgan draws on decades of experience across defense, intelligence and technology to examine how organizations can sustain compliance as environments, priorities and responsibilities change.

Cybersecurity compliance is rarely an organization’s primary mission.

A defense agency exists to support national security. A university is focused on educating students. A healthcare system is responsible for patient care, while a commercial enterprise is working to serve customers and grow its business. Each operates under different cybersecurity requirements, but all face the same underlying challenge: compliance must be sustained alongside everything else the organization is expected to accomplish.

Mike Korgan has seen that tension play out throughout more than two decades working across the Department of Defense, Intelligence Community, civilian agencies and technology sector. During his tenure at Microsoft, his work included Zero Trust strategy, secure cloud modernization, AI-driven defense initiatives and large-scale mission systems leadership. Now, as a member of SteelCloud’s Advisory Board, he is helping the company consider how automation can address the operational realities that make cybersecurity compliance so difficult to sustain.

During a recent conversation with the SteelCloud team, Mike was candid about how many organizations experience compliance. They recognize its importance, but it is still an obligation competing for attention, personnel and resources.

In some cases, Mike said, the immediate motivation may be as simple as avoiding a failed assessment, a fine or a “nasty letter.” The people responsible want to meet the requirement and return their attention to the work on which they are primarily measured.

That does not mean they are unconcerned about security. It means compliance programs must operate within the realities of the organization rather than assuming cybersecurity requirements will always take precedence over an urgent mission, business or operational need.

Compliance Has to Survive a Changing Environment

Reaching a compliant state usually comes with a defined objective. An organization is working toward an authorization, certification or assessment, and the effort has an identifiable finish line.

Maintaining that state is different. There is no finish line because the environment continues to change.

Software is updated, new systems are introduced and engineers resolve performance issues. Exceptions are approved to accommodate operational requirements. Each change may be justified, but it can also affect a configuration that was previously reviewed and approved.

That may sound dramatic until you consider how quickly normal IT activity resumes once the assessment is over. The organization has proven where its environment stood at a particular moment. From that point forward, every change introduces another opportunity for the approved baseline and the operating environment to move apart.

Many organizations do not fully appreciate what sustaining compliance will require until they are already responsible for it. Someone must monitor the environment, understand what has changed and determine whether the change affected the security baseline. When a finding appears, the organization must know who is responsible for evaluating it, who has the authority to remediate it and who will verify that the corrective action solved the problem without introducing another one.

It is often at this point, Mike suggested, that teams begin thinking, “I didn’t know this was going to be like this.”

That realization can occur in any sector. A military organization may be coordinating across commands, program offices and contractor teams. A university may have central cybersecurity policies but decentralized IT operations across its colleges and departments. A commercial enterprise may depend on separate infrastructure, application and security teams that each own a different piece of the environment.

When responsibility crosses those boundaries, compliance becomes much harder to manage. A finding may be visible to one team while the technical access or decision-making authority needed to resolve it sits with another. If that ownership was never clearly established, the gap may remain hidden until something has already fallen out of compliance.

The Program Must Outlast the People Running It

Personnel changes make this challenge even more pronounced.

In military and federal environments, leaders may rotate into new assignments every 12 to 18 months. Commercial companies and public institutions experience the same loss of continuity when employees leave, departments reorganize or responsibilities shift between teams.

The person taking ownership may inherit an environment shaped by years of decisions they did not make. Some exceptions may be poorly documented. Other changes may have been understood by the person who implemented them but never recorded in a way that helps the next owner. Deferred remediation and unresolved findings may have quietly accumulated.

Mike described the familiar pattern of a new leader arriving and discovering that the program had not progressed as expected under the previous owner. The responsibility remains, even when the institutional knowledge needed to understand it has left the organization.

That makes a reliable operating history essential. A spreadsheet showing the configuration that was approved three years ago offers little assurance if no one can account for what happened in the years since. Organizations need to understand why changes were made, which exceptions remain valid and whether remediation restored the intended security posture.

Without that continuity, the next assessment becomes an exercise in reconstruction.

Mike recalled one organization whose recertification ultimately cost approximately three times more than its initial certification. The problem was not simply the cost of repeating the assessment. During the intervening years, the environment had changed without enough monitoring or documentation to explain how it reached its current state. Before the organization could prove compliance again, its teams had to piece together years of individual decisions and determine which configurations could still be trusted.

The expense surfaced during recertification, but it had been accumulating for years.

Confidence Depends on Knowing the Current State

For Mike, the most valuable outcome is the ability to know whether the environment has moved away from its approved baseline.

A previous certification cannot provide that confidence. Neither can an audit report or a record of the settings that were originally implemented. Those artifacts confirm what was true at a particular point in time. They do not necessarily reflect the systems operating today.

As visibility declines, so does confidence in every result that follows. Teams may know that a control failed without understanding which change caused it. They may remediate a configuration without knowing whether the adjustment conflicts with an approved exception or operational requirement. Leaders may receive compliance metrics that appear reassuring even though the baseline behind those metrics no longer represents the actual environment.

This is where cybersecurity compliance becomes an operational problem. The requirement itself may be clear, but sustaining it depends on people, processes and technology working together through years of routine change.

When that work relies primarily on manual processes, it becomes difficult to maintain at scale. Skilled cybersecurity and IT personnel spend their time inspecting individual configurations, repeating remediation steps and tracing changes across systems. That labor is costly in any organization. It is especially difficult to justify when qualified people are already scarce and their expertise is needed for decisions involving risk, context and mission impact.

Mike’s view of automation is grounded in that distinction. People should remain responsible for work that requires human judgment.

Creating a More Sustainable Operating Model

The conditions Mike described help explain why he sees value in SteelCloud’s approach and chose to join its Advisory Board.

ConfigOS is designed to create greater continuity between the baseline an organization approves and the environment it operates every day. By automating the implementation, assessment, remediation and sustainment of security configurations, the platform helps teams identify when systems have moved away from their intended state and respond before those deviations become years of unexplained change.

That visibility can also make ownership easier to maintain. When configuration activity, exceptions and remediation are captured in a consistent system, the program becomes less dependent on the memory of whoever happens to be responsible at the time. A new leader or team member can inherit a clearer record of the environment instead of beginning with an investigation into what previous owners may have done.

Automation cannot make every cybersecurity decision for an organization, nor should it. Operational requirements still need to be evaluated. Exceptions still require context, and risk decisions still belong with the people accountable for the mission.

What automation can do is reduce the recurring effort required to keep a known security baseline in place. It can provide the consistency that manual processes struggle to maintain as environments expand and personnel change.

Cybersecurity compliance will continue to compete with other organizational priorities. Systems will keep evolving, urgent operational needs will arise and responsibility will continue moving from one person to another.

A sustainable compliance program must be built to continue through those realities. The goal is not simply to prove that the organization was compliant on assessment day. It is to preserve confidence in the environment every day that follows.