I have personally watched organizations discover the value of cybersecurity at the worst possible time.
Before the incident, the conversation is about innovation, deadlines, and results. It seems crazy to think decision-makers would believe Security concerns can wait, but achieving an objective can often blind people to the bigger picture. Then a data breach exposes information, or a denial-of-service attack interrupts operations, and those same concerns become urgent. People want to know what happened, how quickly it can be fixed, and why the organization was not better prepared.
That shift in attitude is frustrating because cybersecurity had value before the disruption. What changed was leadership's willingness to pay attention.
I have also worked in environments where caution went too far, where useful technology remained off-limits even when I believed there were practical ways to manage its risks. That has consequences, too. People still have work to do, and they may find their own tools when the organization gives them no workable option.
Both experiences have shaped how I think about innovation. We need enough curiosity to try something useful and enough discipline to understand what we are putting at risk. Governance is how an organization makes those decisions, assigns responsibility, and checks whether its assumptions hold up.
Icarus and the confidence that comes with success.
The story of Icarus has lasted because the mistake is familiar. His father, Daedalus, builds wings from feathers and wax, so he and his son can escape. He warns Icarus to stay between the sea and the sun. Icarus becomes caught up in the flight, climbs too high, and the heat melts the wax holding his wings together. [1]
People sometimes overlook that the wings worked. Daedalus made something extraordinary possible because he was willing to try an unfamiliar solution. He also understood its limits. Without that willingness to innovate, there would have been no flight and no escape.
I see two lessons here. Success can make us overconfident, but fear can keep us attached to methods that no longer serve us. The first successful flight does not prove we can climb indefinitely. The possibility of failure does not mean we should never leave the ground.
Organizations struggle with both. Hubris can be the quiet belief that a strong team, a respected vendor, or a history of successful launches makes serious failure unlikely. Security gets postponed because leadership trusts its ability to handle whatever comes next. At the other extreme, an organization can become so comfortable with familiar systems that it treats every new capability as an unacceptable risk. Being accustomed to a technology does not make it secure, and refusing to change can leave people working around limitations the organization should be addressing.
I want security teams to be willing to reconsider an old restriction, and I want leaders to be willing to hear why a promising idea needs more preparation. Both require enough humility to question what we think we know.
Daedalus understood that flight was possible and that the limits mattered. Organizations need that same judgment: a willingness to explore new technology, learn how it behaves, and take its risks seriously before expanding its use.
Why warnings become easier to dismiss.
Psychology offers some useful explanations for that shift. Across five experiments, Nathanael Fast and his colleagues found that feeling powerful could encourage overconfident decisions, including decisions that cost participants money. That does not mean every leader becomes reckless. It does suggest that authority can affect how accurately people judge their own decisions. [2]
A close call can reinforce the wrong lesson. Robin Dillon and Catherine Tinsley found that people often evaluated near misses much like successes. In their studies, near-miss information could lower perceived risk and encourage riskier decisions afterward. [3]
The cybersecurity parallel is easy to imagine. An exposed service is discovered before anyone notices abuse. An employee sends sensitive information to the wrong place, but no visible harm follows. A rushed deployment survives another quarter. Each event is an opportunity to examine what almost happened. It can also become another reason to believe the current approach is fine.
Those studies were not investigations of cybersecurity breaches. They help explain why an organization might mistake an absence of visible damage for evidence that its decisions were sound.
There is also the question of whether people feel able to speak up. In a study of 51 manufacturing teams, Amy Edmondson found that psychological safety was associated with team learning behavior. People need room to acknowledge mistakes, ask for help, and challenge assumptions. [4]
That matters when a security engineer has to tell a senior leader to delay a launch. If raising a concern earns someone a reputation for being difficult, the concern may never reach the person who needs to hear it. An organization can employ excellent technical staff and still make poor risk decisions.
I have worked through this before.
As a young communications technician in the Marine Corps, I worked in environments where even DHCP, the service that automatically assigns network addresses, was treated with suspicion. The concern was that automatic addressing would let just any device onto the network. We assigned addresses manually and tracked them in spreadsheets.
DHCP had real security considerations in its early implementations, including the possibility of rogue servers supplying bad network settings. [5] But manually assigning addresses and tracking them in spreadsheets didn’t confirm that the device physically plugged in belonged on the network. We still needed controls over who could connect, what they could reach, and what activity we could see.
Wi-Fi brought similar arguments. I could see its operational value and wanted to use it, but early wireless security had serious weaknesses. The way forward required stronger authentication, appropriate encryption, careful configuration, and ongoing monitoring. NIST's wireless guidance reflects that broader responsibility across the life of a wireless network. [6]
USB drives were another version of the problem. Their convenience made them useful, while their portability made it easy to move sensitive information or introduce malicious files. Depending on the environment, the response could include approved encrypted media, device restrictions, scanning, or a prohibition on removable storage. NIST's media-use control explicitly allows organizations to restrict or prohibit particular media. [7]
These examples taught me to ask what a control actually accomplishes. Sometimes a restriction is necessary. Sometimes an old restriction survives because nobody has reconsidered it. Either way, the organization should be able to explain the risk and the reason for its decision.
Encryption does not settle governance.
The proliferation of Signal chat illustrates a different problem. Its messages and calls use end-to-end encryption, which provides valuable protection. [8] People understandably see a secure application and assume it is suitable for sensitive work.
But important questions remain about information-exchange requirements for both federal and private industry. Is the recipient authorized to receive the information? Is the device managed? Can the organization preserve the conversation when required? Is that type of information permitted on the service at all?
For federal agencies, NARA's guidance makes clear that electronic messages created or received in the course of agency business can carry records-management obligations, including when personal accounts or devices are used. It also recognizes that failing to provide suitable tools can drive employees toward personal alternatives. [9]
Private organizations face their own retention, discovery, and information-handling requirements. An encrypted message can still go to the wrong person, disappear too soon, or sit outside the systems the organization relies on to account for its work.
This is why shadow IT is often a sign of an unmet operational need. People turn to personal messaging, cloud storage, or other unapproved services because they help get the job done. Understanding that motivation gives security teams a better chance of offering an alternative people will actually use.
A platform can be ready before its people.
Organizations can also move too quickly after deciding to adopt a technology. Software-defined wide area networking, or SD-WAN, is a useful example. It gives teams ways to manage connectivity and apply policy across distributed sites. Cisco's documentation describes centralized policies that influence routing and traffic across an overlay network. [10]
That reach also changes the consequences of a mistake. Depending on the policy's scope, an incorrect change can affect many locations. The engineering team needs to understand the new system well enough to test changes, recognize unexpected behavior, and recover when something goes wrong.
A purchase and a deployment date do not provide that knowledge. People need training, a place to practice, and time to learn how the system behaves under conditions a demonstration never showed them.
When leadership expects immediate results but treats that preparation as optional, it transfers the uncertainty to the people who must operate the system. Their experience with the old environment cannot automatically fill every gap in the new one.
AI brings the same decisions back.
AI combines many of these pressures. Employees can see the value in summarizing documents, reviewing code, or organizing research. If the approved process is slow and the public tool is convenient, some will use the public tool.
That is how an internal document, customer record, or piece of source code can end up in an external service without the organization having approved that service for the information.
We should describe that risk accurately. Submitting a prompt does not automatically mean a model permanently learns the information or adds it to its training data. With an external AI service, the immediate fact is that the information has been transmitted to another provider. What happens next depends on the service, account, settings, and contractual terms.
The review should examine retention, access, deletion, and any use of submitted content to improve the model. A promise not to train on business data answers one question. It does not settle whether the organization has authorized that service to process a particular document. NIST's generative AI guidance treats data privacy and information security as risks that require their own attention. [11]
Buying an enterprise platform is only the beginning. Connecting it to internal repositories can make existing permission mistakes more consequential. Giving an AI agent the ability to send messages or change records introduces decisions about authority, oversight, and recovery.
The response should match the use. Helping draft public marketing copy is a different proposition from processing privileged legal material or allowing an agent to make production changes. NIST's AI Risk Management Framework frames those questions around intended use, risk tolerance, and ongoing evaluation. [12]
I would start with a defined task, limited access, and information the organization has approved for that purpose. Expand only when the team understands what the system does, where it fails, and how someone can intervene. Give employees a clear route to request useful capabilities so the policy has a practical way forward.
Paying attention before the incident.
The organizations I described eventually paid attention to cybersecurity. A breach or denial-of-service incident made the consequences immediate. The same risk that had seemed abstract was suddenly affecting real work.
I would rather see that attention arrive while there is still time to make considered choices. Leaders should ask what a proposed capability can expose or interrupt, who owns that risk, and what evidence supports proceeding. Security staff should explain their concerns in terms the organization can use, including what would make a proposal acceptable.
NIST's Cybersecurity Framework 2.0 gives governance an explicit role, including risk strategy, leadership responsibilities, and oversight. [13] In practice, that means a decision to accept risk should have an accountable owner. It also means funding the training and preparation needed to make that decision credible.
Some proposals should move quickly. Others need a limited trial, more safeguards, or a firm refusal. The consequences matter more than the desire to appear innovative or cautious. A hospital, a military network, and a development lab cannot all make the same assumptions about an acceptable failure.
I still think about how tragic Icarus’s story is. Daedalus just wanted to fly, and his son didn’t heed his warnings. That is the kind of judgment I want organizations to bring to new technology: enough ambition to build something useful, and enough humility to listen before the wax starts to melt.
Notes:
[1]. Ovid, Metamorphoses, trans. Brookes More (Boston: Cornhill Publishing Co., 1922), 8.183–235, https://www.theoi.com/Text/OvidMetamorphoses8.html.
[2]. Nathanael J. Fast et al., “Power and Overconfident Decision-Making,” Organizational Behavior and Human Decision Processes 117, no. 2 (2012): 249–60, https://doi.org/10.1016/j.obhdp.2011.11.009.
[3]. Robin L. Dillon and Catherine H. Tinsley, “How Near-Misses Influence Decision Making Under Risk: A Missed Opportunity for Learning,” Management Science 54, no. 8 (2008): 1425–40, https://doi.org/10.1287/mnsc.1080.0869.
[4]. Amy Edmondson, “Psychological Safety and Learning Behavior in Work Teams,” Administrative Science Quarterly 44, no. 2 (1999): 350–83, https://doi.org/10.2307/2666999.
[5]. Ralph Droms, Dynamic Host Configuration Protocol, RFC 2131 (March 1997), sec. 7, https://doi.org/10.17487/RFC2131.
[6]. Murugiah Souppaya and Karen Scarfone, Guidelines for Securing Wireless Local Area Networks (WLANs), NIST Special Publication 800-153 (National Institute of Standards and Technology, February 2012), vi–vii, 8, https://doi.org/10.6028/NIST.SP.800-153.
[7]. Joint Task Force, Security and Privacy Controls for Information Systems and Organizations, NIST Special Publication 800-53, rev. 5 (National Institute of Standards and Technology, September 2020, updated December 10, 2020), control MP-7, https://doi.org/10.6028/NIST.SP.800-53r5.
[8]. Signal, “Is It Private? Can I Trust It?,” accessed September 20, 2026, https://support.signal.org/hc/en-us/articles/360007320391-Is-it-private-Can-I-trust-it.
[9]. National Archives and Records Administration, “Guidance on Managing Electronic Messages,” NARA Bulletin 2015-02, July 29, 2015, questions 3–8, https://www.archives.gov/records-mgmt/bulletins/2015/2015-02.html.
[10]. Cisco, “Centralized Policy,” in Policies Configuration Guide for vEdge Routers, Cisco SD-WAN Release 20, updated August 26, 2022, https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/policies/vedge-20-x/policies-book/centralized-policy.html.
[11]. Chloe Autio et al., Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1 (National Institute of Standards and Technology, July 2024), secs. 2.4 and 2.9, https://doi.org/10.6028/NIST.AI.600-1.
[12]. National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (January 2023), secs. 1.2.2 and 5, https://doi.org/10.6028/NIST.AI.100-1.
[13]. National Institute of Standards and Technology, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (February 26, 2024), 3, 17, https://doi.org/10.6028/NIST.CSWP.29.