Ernest Blankson, CISSP, CGRC, discusses an often-overlooked dimension of cybersecurity awareness and incident response: human performance under pressure. Employees are frequently taught how to recognize phishing messages and other warning signs, but organizations spend less time preparing them to manage their initial reactions after they believe an incident may have occurred.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
The aircraft door opened and the wind rushed into the cabin. A few moments later, I was falling through the sky at more than 100 miles per hour.
I expected fear. Instead, I felt calm.
I was skydiving with members of the ISC2 Northern Virginia Chapter. During the free fall, my tandem instructor noticed how composed I was. His observation stayed with me because the environment was loud, fast and unforgiving. Yet I could still pay attention, respond to direction and remain present.
That calm was not the absence of danger but the product of preparation. Before we boarded the aircraft, the instructor explained what would happen, what I needed to do and what signals he would use. Our roles were clear. I did not have to invent a response while falling. I had to recognize the moment and follow what we had practiced.
Cybersecurity work creates a similar challenge. A ransomware alert, compromised account, critical vulnerability, zero-day advisory, missed remediation deadline or difficult stakeholder conversation can place professionals in an environment of speed, uncertainty and pressure. In those moments, technical knowledge matters. So does the ability to control the first reaction, establish the facts, communicate clearly and follow a disciplined process.
Cybersecurity awareness emphasizes prevention, but it must also prepare people to respond when something goes wrong.
The First Reaction Can Change the Outcome
In my cybersecurity work, I have seen how quickly uncertainty can spread during the opening stages of a potential incident. One person wants to disconnect a system immediately. Another starts sending updates before the facts are confirmed. An employee may delete a suspicious email to make the problem disappear. A stakeholder may wait to report an error because they fear being blamed.
Each reaction is understandable. Each can also complicate the investigation. Deleting a message may remove useful evidence. Disconnecting a system without coordination may disrupt logging or business operations. Premature conclusions can send responders in the wrong direction. Delayed reporting gives an attacker more time.
I learned this lesson earlier in my career. When a serious alert arrived, the strongest responders did not confuse urgency with haste. They slowed the conversation just enough to ask disciplined questions: What do we know? What is still an assumption? What evidence must be preserved? Who has authority to make the next decision? That brief pause did not delay the response. It made the response more precise.
When an event became an incident, calm also helped us move through the incident management process. We had to establish severity, document the initial facts, assign technical workstreams and coordinate containment across teams responsible for endpoints, identity, infrastructure, cloud services and business operations. At the same time, leaders needed concise updates and system owners needed to understand the operational impact of proposed actions.
Containment was only one stage. We also had to identify and remove the cause, validate that affected services could return safely and continue monitoring for signs of recurrence. After recovery, we documented lessons, updated procedures and assigned follow-up actions. The process worked best when one person maintained a clear view of decisions, owners and next steps while specialists focused on their assigned tasks. Calm communication kept multiple stakeholders moving through severity assessment, containment, eradication, recovery and lessons learned instead of creating competing responses.
Staying Calm While a Critical Vulnerability Remains Open
Incident pressure does not always begin with an active compromise. It can begin when a scan, advisory or threat-intelligence report identifies a high-risk vulnerability in a critical system. I have coordinated remediation efforts where application teams, infrastructure engineers, security operations personnel, vendors and leadership all needed different information. Security wanted the exposure reduced quickly. Technical teams needed time to test the change. Business owners worried about service disruption. Leaders wanted to understand the residual risk and the deadline for resolution.
Those situations test a security professional's composure. Repeating that a vulnerability is critical does not make a patch safer to deploy. My role has been to keep the risk visible while creating a disciplined path to resolution: confirm the affected assets, validate exploitability and exposure, identify accountable owners, agree on testing and deployment milestones and escalate missed commitments. Where immediate remediation was not possible, we documented temporary safeguards such as access restrictions, additional monitoring, configuration changes or service isolation. We also kept the exception time-bound and reassessed the risk as new information became available.
Zero-day vulnerabilities intensify this challenge because the organization may be exposed before a vendor patch exists. I have monitored government and industry threat reporting, worked with vendors and technical teams for updated remediation guidance and helped teams evaluate interim protections while waiting for a tested patch. The temptation is either to panic or to wait passively for the vendor. Neither is sufficient. Teams should inventory affected systems, examine available indicators, adjust detection and monitoring, restrict unnecessary access, assess whether vulnerable features can be disabled and prepare a deployment plan before the patch arrives. Vendor communication should have a clear owner so new advisories, mitigations and patch updates reach the right teams quickly.
Once the patch becomes available, urgency still requires control. Technical teams must test for compatibility, plan rollback, prioritize internet-facing and mission-critical assets and verify installation. Leaders need an honest view of what remains exposed. Maintaining calm does not reduce the severity of the vulnerability. It allows the organization to make defensible decisions while moving as quickly as operational conditions permit.
Communication is what keeps this work coordinated. Application teams may focus on stability, infrastructure teams on deployment, security teams on exploit activity, vendors on product guidance and system owners on mission impact. Without a shared operating picture, each group can take a reasonable action that conflicts with another group's work. I have found that short, scheduled updates are more effective than a constant stream of fragmented messages. Each update should distinguish confirmed facts from assumptions, state the current exposure, identify interim safeguards, record decisions and show the owner and deadline for every next step.
Executives and system owners do not need every technical detail, but they do need enough information to make risk and operational decisions. I focus their updates on what is affected, whether exploitation has been observed, what protections are in place, what the vendor has communicated, when the patch is expected and what decision or support the response team needs. This approach maintains urgency without amplifying fear. It also gives technical teams room to test and deploy safely while keeping accountability visible.
Calm When Stakeholders Disagree
Not every high-pressure cybersecurity moment involves malicious activity. Some of the most difficult situations begin in a meeting. A system owner may challenge the severity of a finding. An application team may believe a remediation deadline is unrealistic. An executive may want a simple answer when the evidence is incomplete. A vendor may provide guidance that does not address the organization's operational constraints.
I have learned that matching frustration with frustration rarely moves the work forward. The goal is to keep the discussion anchored in the risk: what is vulnerable, what could happen, which safeguards already exist, what remains exposed and which decision is required. listen for the stakeholder's underlying concern, whether it is service availability, limited resources, competing deadlines or fear of accepting responsibility. Acknowledging that concern does not mean lowering the security standard. It creates a path toward an achievable remediation plan.
Calm communication also requires boundaries. When stakeholders disagree, document the decision, owner, milestone and residual risk. If the risk remains outside tolerance, escalate it through the established governance process without making the disagreement personal. The goal is not to win an argument. It is to help the organization make a deliberate, visible and defensible risk decision.
The CALM Framework
After the jump, several of us reflected over tacos. During the conversation we observed that cybersecurity professionals, like skydivers, must remain calm during high-pressure situations. From that conversation, we coined a simple framework: CALM.
- Control the initial reaction: Pause before clicking again, deleting information or attempting an improvised fix. If you suspect compromise, avoid interacting further with the message or system unless your organization’s procedure directs you to do so. Calm does not mean ignoring urgency. It means preventing emotion from making the first decision.
- Assess what is known: Separate verified facts from assumptions. Record what happened, when it occurred and what you observed. Responders should identify the affected accounts, devices or services while preserving logs and other relevant evidence. Clear facts support sound containment decisions.
- Link with the right people: Engage the people who own the risk, technology and decision. Depending on the situation, this may include security, information technology, system owners, vendors, legal counsel, communications and senior leadership. Clear escalation paths reduce confusion and keep fragmented information from driving competing actions.
- Move according to practiced procedures: Follow the relevant incident, vulnerability, remediation or risk-governance process. Teams should know who can isolate a device, approve downtime, test a patch, accept residual risk and communicate with stakeholders. Procedures are most useful when people understand them before pressure rises.
Calm Is an Organizational Capability
We sometimes describe calm under pressure as a personal trait: Some people have it and others do not. My skydive suggested something different. Calm can be created by the people around us. I could remain composed because my tandem instructor had prepared me, communicated clearly and projected confidence. I could take my emotional cues from someone who understood the environment and knew how to guide me through it.
Cybersecurity managers and supervisors have the same responsibility. Professionals reporting to them will notice how they respond when a critical alert arrives, a remediation deadline is missed or a stakeholder becomes confrontational. A leader who communicates panic can spread panic. A leader who remains calm, competent and clear gives the team room to think. Calm is contagious.
I learned this from my own manager, who has consistently remained calm and competent through difficult situations. She listens, asks focused questions and keeps the team centered on what must happen next. That example shapes how I approach incidents, remediations and challenging stakeholder conversations. It has shown me that mentorship happens through behavior, not only formal coaching.
Leaders can reinforce that behavior through cross-functional exercises, simple reporting channels and clear decision authority. A sound playbook can still fail if nobody knows who may approve an action or how to reach a decision-maker after hours.
Psychological safety also matters. People who expect blame may hide mistakes or delay reporting. Leaders should make prompt escalation the expected behavior, including when someone has made an error.
After a drill, incident or remediation, teams should examine technology and behavior. Did participants understand their roles? Were facts separated from assumptions? Did pressure cause anyone to bypass the process? These questions make calm performance a capability that can be developed.
Preparing for Cybersecurity's Difficult Moments
Cybersecurity Awareness Month is a useful time to remind people how to recognize threats. It should also prepare cybersecurity professionals and organizational stakeholders for the difficult moments that follow: uncertain evidence, unresolved vulnerabilities, operational tradeoffs, vendor delays and competing priorities.
No organization can eliminate uncertainty from cybersecurity. New information will arrive, initial assumptions will change and difficult decisions will still be required. Preparation does not remove the chaos. It gives people a way to move through it.
When I stepped out of the aircraft, I was entering an environment I could not control. What I could control was my response. I could listen, remember the preparation and work with the person trained to guide me safely to the ground.
That is the standard our cybersecurity programs should pursue. We should prepare people not merely to know that cyber risk exists but to act with discipline when it becomes real. Whether we are managing an incident, coordinating a critical remediation, waiting for a zero-day patch or working through stakeholder resistance, calm is not passive. It is a cybersecurity capability.
Ernest Blankson, CISSP, CGRC, is a senior risk advisor with more than 10 years of experience in cybersecurity operations, risk management and governance. He is an active member of the ISC2 Northern Virginia Chapter.
