Skip to content
CISOteria

Tag: CISOteria

Regulatory Change Management: Build Once, Map Many

Posted on by CISOteria

 Why Regulatory Change Creates So Much Rework 

Regulatory change management becomes difficult when security frameworks are built to mirror regulations too closely. Security frameworks are built over years. Regulations are not. 

A new regulation, amendment, supervisory expectation, or reporting obligation can introduce requirements much faster than an organization can redesign its security program. If the framework was built too closely around the wording of a particular regulation, even a relatively small regulatory change can trigger a disproportionate amount of work: controls need to be rewritten, policies updated, evidence requirements reconsidered, and teams asked to implement processes that may already exist elsewhere. 

A mature security framework should be able to absorb regulatory change without being rebuilt from zero. The goal is to maintain a stable set of security controls, policies, and processes while allowing regulatory requirements to be added, removed, or modified through a separate mapping layer. 

Recent research supports this direction. Canavese et al. examine five overlapping EU regulatory instruments and argue that treating them as isolated regimes creates unnecessary complexity. Their compliance-by-design approach instead looks at how obligations intersect and how overlapping requirements can be satisfied without duplication.

The practical question for CISOs is therefore not simply: Are we compliant with the regulation today?

It is: If the regulation changes tomorrow, how much of our security framework will we have to rebuild?

 

What Is Regulatory Change Management?

Regulatory change management is the ongoing process of identifying new or amended requirements, assessing their impact, and updating the controls, policies, processes and evidence they affect. In cybersecurity, the aim is to maintain compliance as requirements evolve without duplicating work or destabilising the underlying security programme.

 

Principle 1: Build Around Security Objectives, Not Regulatory Clauses

One of the easiest ways to create future compliance work is to structure the security framework as a mirror of a particular regulation. 

A regulation says organizations must manage vulnerabilities, so a regulation-specific vulnerability control is created. Another regulation introduces a similar requirement, so another control is added. A third framework addresses the same underlying security objective using slightly different terminology, creating yet another policy, assessment, or evidence request. 

Over time, the organization may end up managing several compliance structures that describe largely the same security activities. 

This becomes increasingly difficult as regulations overlap. Canavese et al. note that legal acts may have overlapping scopes but different thresholds, procedures, and timelines, including in areas such as vulnerability management and reporting. Managing several regulations concurrently therefore increases day-to-day operational complexity. 

A more resilient model separates the security requirement from the regulatory requirement. 

For example, the organization may maintain one internal control for vulnerability management that defines: 

  • ownership and responsibilities;
  • vulnerability identification;
  • risk-based prioritization;
  • remediation expectations;
  • exception handling;
  • reporting;
  • evidence requirements.

Different regulatory requirements can then be mapped to that same control. 

The internal control remains relatively stable. The regulatory mappings are designed to change.

Different regulations often converge on similar security outcomes. In their cross-regulatory analysis, Canavese et al. explicitly focus on translating legal requirements into actionable artifacts such as security controls, architectural constraints, and organizational processes.

Instead of building a new security program every time another regulation becomes applicable, the organization can first ask: Which parts of this requirement are already covered by our existing controls?

Only the remaining gap should create new work.

Principle 2: Map Requirements to Reusable Controls  

For this model to work, the relationship between controls and regulatory requirements cannot live only in someone’s spreadsheet or institutional knowledge.

It needs to be explicit.

Trace Requirements to Controls 

Akinsanya’s 2025 security-by-design framework includes a dedicated compliance mapping component designed to connect security controls with regulatory requirements. The model emphasizes bidirectional traceability, allowing an organization to see both which regulatory requirements a control supports and which controls support a particular requirement.

That traceability becomes particularly important when regulation changes.

Follow the Change Path 

Consider an organization with an existing incident-response control. A new regulatory amendment introduces a shorter reporting deadline.

If the relationship between the regulation, control, policy, procedure, and evidence is already mapped, the organization can identify exactly where a regulatory change has an impact without reviewing the entire cybersecurity framework. It can trace the changed requirement to the relevant control, then to the affected policy or procedure, and finally to the evidence that may need to be updated. 

Perhaps the incident-response process, roles, escalation paths, and testing remain valid. Only the notification timeline and the procedures or evidence connected to it need to change.

Without that traceability, even a small regulatory amendment can become an organization-wide discovery exercise.

Principle 3: Assess the Regulatory Delta 

The objective of regulatory change management should therefore be to identify the delta: what has actually changed between the organization’s current framework and the new requirement. 

That sounds simple, but it requires the framework to be designed for it.

Controls should be sufficiently modular that one requirement can change without forcing unrelated parts of the framework to change with it. Policies should describe durable organizational principles rather than copy regulatory language unnecessarily. Regulatory references should be maintained separately from the operational logic of the control.

The same principle applies across multiple regulations.

Canavese et al. argue for viewing cybersecurity legislation as an interconnected system rather than a collection of independent regimes. Their analysis specifically considers how overlapping obligations can be addressed in ways that avoid duplication.

What Actually Needs to Change? 

For CISOs, the practical implication is significant. When a new regulation appears, the first task should not be to build a new framework. It should be to map the new requirements against the framework that already exists.

The result will usually fall into three groups:

  1. Already covered.
    The existing control and supporting policy already satisfy the requirement.
  2. Partially covered.
    The existing control is relevant, but a parameter, procedure, evidence requirement, or scope needs to change.
  3. Not covered.
    The regulation introduces a genuinely new obligation that requires a new or substantially expanded control.

Only the third category should normally require additional control design or implementation. 

Keep the Security Core Stable 

There is another reason to avoid designing the framework directly around regulatory clauses: compliance and security do not change at the same speed.

Akinsanya argues that traditional compliance-centric approaches can prioritize retrospective audits over proactive risk mitigation and describes the need to bridge regulatory requirements with actionable security practices.

The proposed framework addresses this by combining compliance mapping with continuous validation and adaptive governance. Findings such as compliance gaps, vulnerabilities, and incident data are fed back into governance decisions so that policies and controls can be updated as both threats and regulatory requirements evolve.

That adaptability becomes critical when regulatory requirements change.

A regulatory update may require the organization to change how quickly it reports an incident, how long it retains particular evidence, who approves a decision, or how a control is documented.

Those changes should be possible without destabilizing the underlying security program.

The security architecture should provide continuity. The regulatory layer should provide adaptability.

Build Once, Map Many: How CISOteria Supports Regulatory Change Management 

CISOteria is built around a shared compliance structure rather than treating every framework as a separate project.

Controls are mapped across multiple frameworks, so the same control does not need to be assessed and managed again for every regulation. This creates a common control layer that can continue to support the security program even as regulatory requirements change.

Policies are connected to those frameworks and controls as well. When a regulatory requirement changes, CISOteria’s Cyber OS can surface the policies affected by that change, helping teams identify where an update is actually required instead of reviewing the entire policy library.

The same structure keeps evidence connected to the relevant controls and maintained continuously. This creates a clear path from regulatory change to the specific areas that require attention. 

Instead of reviewing the entire compliance program, teams can see where action is needed, what must be updated or completed, and which existing controls and policies remain valid.

Conclusion: Build for Change

Regulatory change should not force organizations to rebuild their security programs from the ground up.

The more resilient approach is to maintain a stable control framework, map regulatory requirements to it, and treat each change as a gap-analysis exercise. Existing controls, policies, and processes should remain in place where they still satisfy the requirement, while updates are limited to the areas where expectations have genuinely changed.

For CISOs, this keeps compliance connected to security rather than allowing every new requirement to create another isolated layer of work. The goal is not simply to comply with the regulation that exists today, but to build a framework capable of adapting to the one that comes next.

For Further Reading

This blog post is based on insights and analysis from:

  • Akinsanya, Ayokunle. “Security by design: a risk-based framework for cybersecurity compliance and critical infrastructure protection.” International Journal of Information Security 24.6 (2025): 234. 

https://doi.org/10.1007/s10207-025-01155-4   

  • Canavese, Daniele, et al. “Uncovering challenges of cybersecurity cross-regulation in EU legislation.” Information and Software Technology (2026): 108033. 

https://doi.org/10.1016/j.infsof.2026.108033  

Cyber Crisis Communication: What to Say While an Incident Is Still Unfolding

Posted on by CISOteria

Cyber Crisis Communication Starts Before You Have All the Answers

In one of our previous discussions on post-incident recovery, we looked at the role communication plays after the immediate crisis begins to ease. Even when systems are restored, customers, employees, partners, regulators, and the board may still need explanations, evidence of corrective action, and reasons to believe the organization has regained control.

But communication does not begin when the incident ends.

Cyber crisis communication begins before the investigation is complete. While security teams are still containing the incident and establishing the facts, executives, employees, customers, and regulators may already need answers. 

At that stage, the forensic investigation may still be incomplete. The scope may change. Some information may be too sensitive to share. Different stakeholders may need different answers, and every statement the organization makes can affect what happens next. 

The organization is therefore expected to communicate at exactly the moment when certainty is lowest. 

This is where crisis communication differs from post-incident trust repair. The immediate challenge is to keep people informed while containment, investigation, recovery, and sometimes negotiations with the attacker are still underway.

Recent research identifies this as one of the characteristics that makes cyber crisis communication different from more traditional crisis communication. In many crises, communication follows the disruptive event. In a cyber incident, communication frequently happens while forensic investigation and operational response are still in progress.

A public statement can affect a ransomware negotiation. Information shared internally may reach an attacker. In a third-party breach, an organization may depend on another company’s investigation before it can answer its own customers. 

For CISOs, the challenge begins before the full picture is available: how do you communicate while the incident is still unfolding?

Communication Is Part of Cyber Incident Response

Cyber incident response is often described through technical activities such as detection, analysis, containment, eradication, and recovery.

Communication runs through the same process.

A 2025 study on cybersecurity crisis communication argues that organizations need structured communication protocols throughout the incident lifecycle rather than ad hoc messaging. Its proposed model integrates communication into notification and escalation, analysis and response, external stakeholder communication, and post-incident review. 

Poor communication can make an already difficult incident harder to manage. Different teams may work from different versions of the situation. Executives may receive information that has already changed. Customer service may answer questions before an agreed position exists. Employees may learn developments through the media. Legal, security, communications, and management may each apply a different standard when deciding what can safely be shared. 

The result is fragmentation at exactly the moment when the organization needs a common understanding of what is happening.

The same 2025 research emphasizes predefined roles, escalation paths, communication responsibilities, and structured information sharing across technical, legal, management, and public relations teams. 

Knowing who communicates is therefore only the first step. The harder decision is determining what can responsibly be said while the facts are still changing.

The Goal Is Clarity Under Uncertainty

In the early hours of a serious cyber incident, the organization may still have only a partial picture. Even so, waiting to communicate may not be practical. 

The organization should clearly separate confirmed facts from information that is still uncertain. A useful update can explain what has been confirmed so far, what the investigation is still examining, what actions are already underway, which groups appear to be affected based on current evidence, and when more information is expected. 

The 2026 study supports this approach by highlighting the value of communicating what is known, what remains under review, and what is still unclear. 

This allows the organization to provide useful information without presenting an incomplete forensic picture as a final conclusion.

Build a Cyber Crisis Communication Plan Before You Need It

The worst time to decide how cyber crisis communication works is when the incident is already unfolding.

By then, information is changing quickly. Technical teams are focused on containment. Legal teams may be assessing reporting obligations. Executives want answers. Employees and customers may already be asking questions.

A communication plan therefore needs to define the process rather than predict the exact wording of a future statement.

The 2025 research emphasizes predefined roles, escalation paths, communication channels, stakeholder engagement, and coordination between security, management, legal, and communications functions. The 2026 research goes further, arguing that communication should remain closely connected to forensic and operational work because communication decisions can directly affect negotiations, investigations, and containment. 

For CISOs, preparation means establishing how technical information reaches decision-makers, how uncertainty is communicated, how earlier statements are updated, how alternative channels are activated when normal systems fail, and how critical suppliers are expected to share information during an incident. 

The aim is to reduce improvisation when pressure is highest and keep communication connected to the live response. 

CISOteria can support this process by keeping risks, responsibilities, decisions, and follow-up actions connected in one operational view. This gives security leaders a clearer picture of what is known, who owns the next step, and which stakeholders need to be involved as the incident develops.

One Incident Does Not Mean One Message

A cyber incident rarely has a single audience. 

The 2025 research identifies audience adaptation as an important part of structured cyber crisis communication. Technical teams, executives, regulators, customers, and the media have different information needs, requiring messages to be adapted to each audience to reduce the risk of misunderstanding. 

Employees Need Direction

Internal communication becomes especially important when the incident begins affecting daily operations.

Employees may lose access to systems, remote work tools, shared files, or normal communication channels. They may also receive questions from customers, partners, or other external contacts before the organization has published a broader update.

The 2026 study describes employees as both affected participants and important parts of the wider information environment. What they understand, what they repeat, and how they respond to questions can influence the course of the incident.

Internal communication should therefore focus on practical direction. Employees need to understand which systems are safe to use, which alternative channels have been approved, where questions should be directed, and what information should remain restricted.

Executives Need Decision-Relevant Information

Executives have a different information need.

They usually do not need every forensic artifact or technical hypothesis. They need enough reliable information to understand the business consequences and make decisions while the investigation continues.

The CISO therefore has to translate a changing technical picture into decision-relevant information. That may include the operational impact, possible exposure of customer data, regulatory implications, dependencies on third parties, the status of recovery, and any communication decision that could affect the investigation or negotiations.

The Attacker May Be Listening Too

Cyber incident communication must account for the possibility that threat actors are monitoring what the organization says publicly – and potentially internally.

The 2026 research repeatedly notes that threat actors may monitor public communication and, depending on their level of access, may also be able to observe internal communication.

External communication can unintentionally reveal useful details to the attacker. A statement may expose information about disruption, recovery progress, priorities, or the organization’s negotiating position. 

Organizations should therefore consider the operational impact of a message before publishing it. 

Cyber Crisis Communication Depends on the Type of Incident

Cyber crisis communication does not follow one fixed template. The right approach depends on the type of incident and the operational risks created by disclosure. The 2026 research highlights several important differences: 

  • Ransomware: Communication may affect negotiations, reveal the scale of disruption, or expose recovery capabilities. Organizations need to keep stakeholders informed while preserving enough flexibility to adapt as the incident develops.
  • Third-party compromise: The organization may need to communicate with its own customers while depending on the compromised supplier for forensic information. Clear pre-incident agreements on information sharing, update timing, and external communication can reduce delays and confusion.
  • Nation-state espionage: Broad communication may compromise an ongoing investigation or alert an attacker who is still active. Early communication may therefore need to remain limited to a small need-to-know group, sometimes through alternative channels.

The key point is that timing, transparency, and the level of detail should reflect the operational context of the incident. In some cases, faster communication is necessary. In others, restraint protects the response. 

Message Framing Comes After Evidence

Once the organization has established what it can responsibly confirm, it still has to decide how to explain the incident. 

Research presented at ECIS 2025 examined 7,941 U.S. data breach disclosures and found that organizations rarely rely on a single response strategy. The researchers identified 18 distinct combinations, including approaches such as compensation, apology, justification, excuses, and presenting the organization as a victim of the attack. 

These choices shape how the organization explains responsibility and responds to those affected. 

For CISOs, however, the factual foundation needs to come first. The organization may want to reassure customers or explain the actions already taken, but the message should remain within the boundaries of what the investigation can support. 

Conclusion: Communicate With the Incident as It Develops

Cyber crisis communication takes place while the facts are still developing.

Security teams may still be investigating while executives, employees, customers, partners, and regulators already need information. The organization therefore needs a communication process that can evolve with the incident.

That means keeping messages aligned with the current evidence, adapting information to the needs of different audiences, and considering how disclosure could affect the operational response.

This is what separates crisis communication from post-incident trust repair. Post-incident communication addresses what happens after the immediate crisis. Crisis communication helps the organization navigate the period when the outcome is still uncertain.

A mature incident response plan should therefore define how communication works before the first urgent request for an answer arrives.

For Further Reading

This blog post is based on insights and analysis from:

  • Covarrubias, Jersain Zadamig Llamas. “Effective communication as a pillar of cybersecurity: Managing incidents and crises in the digital era.” Journal of Risk Analysis and Crisis Response 15.2 (2025): 34-34.
    https://doi.org/10.54560/jracr.v15i2.564 
  • Jechle, Deinera, Sebastian Schuetz, and Heiko Gewald. “Decoding Data Breach Response Strategies: Insights from Situational Crisis Communication Theory using Topic Modeling.” ECIS. 2025. 

https://www.researchgate.net/publication/393568155_Decoding_Data_Breach_Response_Strategies_Insights_from_Situational_Crisis_Communication_Theory_using_Topic_Modelling 

  • Jong, Wouter, Kelly Mikelatou, and Marcel Vielvoije. “When Crisis Communication Meets Forensics: Managing Narratives in Ransomware, Third-Party, and Nation-State Attacks.” Computers & Security (2026): 105082. 

https://doi.org/10.1016/j.cose.2026.105082 

The Board Is Asking Cybersecurity Questions. But Can It Judge the Answers?

Posted on by CISOteria

The Board Has the Answers. Does It Understand Them?

A board can review every cybersecurity report, ask every recommended question, approve more investment, and still fail to govern cyber risk properly.

Cybersecurity has quietly changed the job description of the board, not because directors are expected to understand malware, analyse attack techniques, or debate the merits of competing security technologies, but because cyber incidents increasingly determine whether an organisation can continue operating, comply with regulatory obligations, preserve stakeholder trust, and execute its strategy. 

The discussion has therefore moved from technology to governance. This raises an uncomfortable question that many boards still need to answer: what does real accountability for cybersecurity look like?

For years, the answer seemed simple. Cybersecurity became a regular board topic, the CISO gave quarterly updates, dashboards became more detailed, and directors approved more spending or asked for independent reviews. From the outside, this looked like strong governance.

Recent academic research suggests that the reality is more complicated.

When Oversight Becomes Theatre 

A Full Agenda Is Not Proof of Governance 

One of the most important findings from recent research is not simply that boards struggle with cybersecurity. It is that many directors believe they are providing effective oversight, while cybersecurity specialists looking at the same process disagree.

The researchers interviewed directors, cybersecurity executives, and senior consultants, while also reviewing 1,000 firms from the Russell 3000. Only 14.7% reported having at least one director with cybersecurity or closely related expertise. More than half of the non-expert directors interviewed believed that specific cybersecurity expertise was not necessary for effective oversight, while none of the expert directors agreed.

The difference was not about effort. Non-expert directors attended meetings, reviewed reports, completed training, and asked questions just as expert directors did. The problem was that these activities could still remain symbolic if directors did not have enough knowledge to understand which information was truly reassuring and which information should change the board’s view of risk.

Governance is not measured by how many meetings are held or how many reports are reviewed. It is measured by whether directors can challenge assumptions, influence important decisions, and recognise when positive metrics hide serious weaknesses.

The researchers describe this as the difference between symbolic and substantive oversight. Symbolic oversight looks like governance. Substantive oversight improves the decisions that follow.

More Dashboards, Same Blind Spot 

Reports Still Need Context

The natural response to weak oversight is often to give directors more information: more dashboards, more indicators, more reports, and more external reviews.

But the problem is often not a lack of information. It is a lack of context, interpretation, and challenge.

A lower number of critical vulnerabilities may mean security has improved, but it may also mean the organisation changed how it measures them or reduced the scope of its scanning. High compliance scores may show that processes are being followed, but they may say very little about whether the organisation can continue operating during an attack. A positive assurance report may confirm that a review took place without showing whether it covered the systems, suppliers, and dependencies that matter most.

Without context, information can create confidence instead of understanding.

The information gap may also be larger than boards realise. In a supporting survey, CISOs estimated that the median share of peers who filtered reports to make themselves or their managers look better was 40%. The study does not prove that 40% of board reports are false, but it does show that experienced security leaders see selective reporting as a real governance risk.

A board without enough expertise may not notice when information has been softened, simplified, or framed to highlight progress. More importantly, it may not realise that there is anything to notice.

Monitoring Does Not Mean Governing 

Another study offers a useful way to think about this issue. Instead of treating oversight as a regular reporting task, the authors argue that boards should approach cybersecurity as an ongoing process of strategic sensemaking.

They describe three activities: scanning, interpretation, and action. These should continue before an incident, during an attack, and throughout recovery.

The board’s role is not to manage cybersecurity operations. It is to make sure the organisation keeps identifying important risks, understands what they mean for the business, and makes decisions that improve long-term resilience.

Accountability Starts Before the Incident

Governance failures often begin long before a cyber incident reaches the boardroom.

They begin when ownership of important risks is unclear, when business leaders assume cybersecurity belongs only to the security team, when supplier risk is reviewed separately from business continuity, or when management’s confidence is not supported by evidence the board can examine.

By the time an incident happens, many of the decisions that shape its impact have already been made. The organisation has already decided which systems are most important, which risks it will accept, which remediation deadlines can move, and which recovery capabilities deserve funding.

Strategic oversight therefore starts with clear ownership, clear decision rights, reliable evidence, and a direct link between cyber risk and business priorities.

The Questions Have Changed

For many years, boards asked whether the organisation had the right controls, whether regulatory duties had been met, or whether audits had found serious weaknesses. Those questions still matter, but they are no longer enough.

A stronger governance discussion asks whether the board understands which cyber risks could affect the organisation’s strategy, who owns those risks outside the security team, what evidence supports management’s confidence, and how directors would know if their current view of risk was no longer correct.

These questions are harder because they do not only ask for information. They ask for understanding.

Smart Directors Can Still Ask the Wrong Questions 

The study does not say that every board must appoint a former CISO. It does show that boards without real cybersecurity knowledge face a greater risk of confusing visible governance activity with effective oversight.

Directors with cybersecurity expertise are more likely to notice gaps, challenge assumptions, test reports, and separate technical detail from business impact. Their value is not mainly in explaining technology. It is in improving the board’s judgement.

One of the most important findings is that directors without cybersecurity expertise often do not realise that their oversight may lack depth. This creates a serious blind spot because boards cannot easily fix a weakness they do not recognise.

That does not mean one expert should carry the responsibility for the whole board. All directors still need to understand how cyber risk affects strategy, operations, finance, compliance, and trust. Expertise should improve the board’s work, not replace shared responsibility.

If Everyone Owns Cyber Risk, No One Does

Both studies point to the same basic issue: effective cybersecurity governance depends on visibility.

Directors need to know who owns important risks, how decisions are made, what evidence supports management’s confidence, which dependencies affect resilience, and how risk is changing across the organisation. Without that visibility, accountability is difficult to test or prove, even when everyone is acting in good faith.

Technology cannot create board accountability, but it can make accountability easier to see, challenge, and support with evidence.

This is where a governance platform can help. Its value is not in creating another separate dashboard, but in connecting risks, ownership, controls, evidence, compliance duties, and third-party relationships in one place.

Conclusion

The Board Will Be Judged by What It Can Prove 

Regulators, investors, customers, and executive teams increasingly expect boards to show not only that cybersecurity appears on the agenda, but that directors understand how cyber risk is governed, challenged, and connected to strategy.

That expectation cannot be met through reporting alone. It requires boards that are willing to question their own assumptions, organisations that can prove accountability instead of only describing it, and governance processes that turn cybersecurity from a technical issue into a business decision.

The boards that govern cyber risk well will not necessarily be those that receive the most information. They will be those that can challenge what they are told, recognise what is missing, and connect cyber risk to the decisions that shape the organisation’s future.

For Further Reading

This blog post is based on insights and analysis from:

  • Lowry, Michelle R., Anthony Vance, and Marshall D. Vance. “Inexpert supervision: Field evidence on boards’ oversight of cybersecurity.” Management Science 72.2 (2026): 783-804. https://doi.org/10.1287/mnsc.2023.0414

The Policy Says One Thing. The Organisation Does Another. Why?

Posted on by CISOteria

Approved on Paper. Ignored in Practice

Most organisations already have security policies.

They explain how employees should handle data, approve access, share files, use devices, and report incidents. On paper, the rules are clear. Responsibilities are assigned, controls are documented, and the organisation can point to a formal process.

Then the policy meets daily work.

An employee cannot complete a task quickly enough through the approved system, so they create a workaround. A manager uses a faster channel because the official process feels too slow. A team adopts an unauthorised tool because the approved one does not fit the work.

The problem is not always that employees do not know the rules. The policy describes how work is supposed to happen, while employees deal with how work actually happens.

On Paper, Everything Works

Knowing the Policy Is the Easy Part

Recent research on information security policy compliance shows that awareness alone is not enough. Employees may understand the rules and still behave differently when the approved process feels difficult, time-consuming, unclear, or disconnected from the pressures of their role. The research describes this as a “knowing-doing” gap: people may know what the organisation expects without consistently following it in practice.

Organisations often assess policy strength through formal evidence: an approved document, completed training records, and a successful audit review. Those signals show that the process exists, but they reveal far less about how employees behave under pressure.

Deadlines, slow systems, unclear instructions, and competing business demands often shape daily decisions more than the policy itself.

Green Checks Can Hide Grey Practices 

A policy may be formally approved, communicated across the organisation, included in training, and reviewed during an audit, yet still remain weakly connected to daily work. From a governance perspective, those visible signs can create a level of confidence that the organisation has not fully earned.

Leadership can see the document, the completion records, and the audit result. It has far less visibility into the small decisions employees make when the official process slows them down, creates extra work, or conflicts with an urgent business need. A team may use an unapproved tool, a manager may accept an informal exception, or an employee may skip a step that seems unnecessary in the moment. None of these actions may appear serious on their own, but together they can create a growing gap between the control environment described in policy and the one that actually exists.

The difficulty is that formal evidence usually records whether a process was designed, approved, or reviewed. It rarely shows how consistently that process is followed under pressure. As a result, an organisation may report strong compliance while the day-to-day reality depends on workarounds, local habits, and decisions that never reach the formal governance process.

Good Intentions Can Create Bad Security 

The Employee Followed Security – Just Not Yours 

A 2025 study examined what the researchers call shadow security practices – unofficial security-related workarounds created by employees who still believe they are protecting the organisation.

An employee may save important files on a personal device because the approved backup system is slow. The intention is protective, but the result is still outside the organisation’s control and may violate data-handling rules.

Shadow security is difficult to manage because the employee may still be trying to protect the organisation. They are balancing a business task with a security requirement, but doing so through a method the organisation cannot see or govern. 

Too Much Security Can Drive Work Underground 

The same study surveyed 433 office workers and found that information security overload increased employees’ intention to use unofficial security practices. When people felt that security duties added pressure, delayed their work, or made primary tasks harder, they were more likely to create their own solution.

This does not mean controls should disappear whenever they create friction. Some friction is necessary because the risk justifies it.

The problem begins when the organisation adds controls without understanding their combined effect. One approval, one authentication step, and one reporting requirement may each seem reasonable. Employees, however, experience the full process. When those requirements accumulate, the approved path may become harder to follow than the workaround.

Another Training Session Will Not Fix the Process 

Security Communication or Security Noise?

The shadow security study found that employees were less likely to create workarounds when they understood how security measures worked, why management required them, and what outcomes the measures were meant to achieve.

However, the study also found that excessive communication can increase overload. More emails, more warnings, and more training do not automatically create better behaviour. They can create confusion, fatigue, and pressure.

The goal should therefore not be maximum communication. It should be useful communication that explains the risk, the reason for the rule, and the practical way to follow it.

Culture Decides Which Rules Survive 

The 2025 systematic review found that policy compliance is influenced by employee attitudes, perceived effectiveness of security measures, management support, awareness, and organisational culture.

Employees notice whether leaders follow the same rules they promote. They notice whether managers reward speed while security demands caution, and whether reporting a problem leads to support or blame.

A policy may say that security is everyone’s responsibility, but the organisation teaches a different lesson when deadlines always win or exceptions are quietly ignored.

Training cannot fix that on its own. If the approved process is too slow, another awareness session will not make it faster. If employees are rewarded for speed and punished for delay, a reminder about compliance will not change the incentive.

Workarounds Are Also Evidence

A workaround should not be accepted simply because the employee had good intentions. Unapproved practices can still create serious risk.

But they should be studied.

A workaround shows where the official process and actual work have separated. It may reveal a missing tool, unclear ownership, a slow approval chain, or a policy that was written without enough operational input.

The organisation should examine both the employee’s decision and the conditions that made the approved process difficult to follow.

Approved, Published, Forgotten  

A policy becomes useful when the organisation can see how it is being applied.

That requires clear ownership, defined controls, evidence, exceptions, and regular review. It also requires visibility into where practice is moving away from policy.

For organisations using CISOteria, this means connecting policies to the controls, owners, evidence, risks, and compliance requirements they are meant to govern. The value is not simply in storing the policy. It is in showing whether the policy is active, who is responsible for it, what proves that it is being followed, and where gaps remain.

CISOteria does not enforce employee compliance. It gives the organisation visibility into whether policy and practice remain aligned.

Conclusion:

The Rules That Survive Pressure Are the Rules You Actually Have 

Every organisation has two versions of its security policy. One is written, approved, and presented during audits. The other is shaped by daily decisions, management behaviour, informal exceptions, and the pressure employees face when they try to get work done.

Good governance begins with recognising the gap between the two. The organisation needs to understand where practice has moved away from policy, why that happened, and whether the right response is stronger enforcement, clearer communication, a better process, or a revised policy.

Because the written policy shows what the organisation intends to do. Daily behaviour shows what it has actually made possible.

For Further Reading

This blog post is based on insights and analysis from: