For years, cybersecurity teams have worked from a relatively straightforward model: identify the critical vulnerability, patch it and reduce the risk.  That model still matters, but it is no longer enough.

The growing concern is not simply that attackers can use AI to write better phishing emails or generate malicious code faster. The bigger issue is that AI can help adversaries connect seemingly benign vulnerabilities into an attack path that security teams may never have considered.

A low-severity application flaw, exposed API, over-permissioned service account, cloud misconfiguration and AI agent with excessive access may not be alarming individually. But when they can be identified, sequenced and exploited together, they can create a serious breach.

This is the new cybersecurity challenge: AI-enabled vulnerability service chaining.

The risk is in the combination

Attackers have always chained vulnerabilities. The difference now is speed, scale and agility.  AI can analyze large volumes of technical information, identify relationships, generate attack hypotheses and rapidly test likely pathways.

Think of it as an attack graph. An attacker might begin with a minor weakness in a public-facing application that reveals information about an internal system. That system could connect to a cloud workload with excessive permissions, which has access to a data repository or AI-enabled workflow. The AI workflow might then have access to customer records, knowledge bases, ticketing systems or network-management tools.

No single failure is necessarily catastrophic. Together, they create a path. That makes traditional vulnerability management insufficient on its own. Security teams have historically focused on CVE scores, patches, affected devices and application owners. In an AI-driven threat environment, they also need to understand the relationships between vulnerabilities and what an attacker can reach next.

The key question has shifted from “How severe is this vulnerability?” to “What does this vulnerability connect to?”

AI changes the attacker’s economics

AI does not need to autonomously execute a complete attack to create material risk. It simply needs to make capable attackers more productive.

AI can help adversaries correlate exposed assets, software dependencies, APIs, identities and cloud configurations; analyze source code and public documentation; generate targeted social-engineering campaigns; modify exploit code more quickly; identify paths from low-value targets to high-value systems; and adapt attacks as defenders change controls.  The result is a shrinking window between vulnerability disclosure and attempted exploitation.

This is especially relevant in highly interconnected enterprises. Modern environments include SaaS platforms, public and private clouds, remote endpoints, mobile devices, APIs, open-source software, managed services and an expanding collection of AI models and agents.

Connectivity creates business value. It also creates pathways.

The agentic AI exposure

Agentic AI raises the stakes because agents do more than answer questions. They can act.  An agent may retrieve enterprise data, open a ticket, issue a command, modify a workflow, query a database or call an API. These capabilities make an AI agent a potentially privileged digital worker.

Organizations should therefore treat AI agents like any other identity with access to enterprise systems. Agents need narrowly defined permissions, explicit tool access, strong authentication, comprehensive logging and clear guardrails.

Prompt injection illustrates the risk. An agent may ingest a document, email, website or support ticket containing hidden instructions designed to manipulate the model. If the agent has broad permissions, that content could become a stepping stone toward data exposure or an unauthorized action.

The potential blast radius grows when an AI system has both access to sensitive data and authority to act.

What CIOs should do now

The answer is not to slow AI adoption. It is to build AI securely while assuming attackers will use AI to discover hidden connections.

1. Build a complete AI inventory

Organizations need visibility into where AI is being used. Inventory models, APIs, agent frameworks, datasets, vector databases, plugins, tool connectors and external services. Document what data each system can access, what actions it can take and who owns the associated security decisions.

Treat this as an AI bill of materials, not simply a software bill of materials.

2. Manage attack paths, not only vulnerabilities

Continue patching critical vulnerabilities but prioritize them in context.

A moderate weakness may require urgent remediation if it is internet-facing, connected to a privileged identity, adjacent to sensitive data or capable of leading to an AI-enabled workflow. Use exposure management and attack-path analysis to understand how vulnerabilities, identities, applications and data stores connect.

The goal is to break the chain before an attacker can assemble it.

3. Make identity the control plane

Apply least privilege to users, applications, service accounts, APIs, workloads and AI agents. Use short-lived credentials, strong authentication, API allowlists and continuous monitoring. Separate agent identities from human identities and require human approval for high-impact actions.

An AI agent should have only the access required to complete a specific task — nothing more.

4. Segment systems and data

Segmentation limits blast radius.  Separate development, test and production environments. Keep sensitive customer and operational data distinct from general knowledge repositories. Separate read-only AI tasks from workflows that can write, execute, modify or approve.

The key question now should not be: “Does this task require this data, at this time, for this purpose?”

5. Test the whole chain

Penetration testing should move beyond individual applications and systems.

Test how an attacker could move across identities, cloud services, APIs, AI agents, data stores and network controls. Include prompt injection, excessive agent permissions, insecure tool connections, exposed secrets and unsafe automation.

We’ve known models can produce a bad answer on its own.  But now consider whether a manipulated model or agent can cause a real business or security outcome.

The bottom line

AI is changing the economics of cyberattacks.  The next major incident may not begin with a single catastrophic vulnerability. It may start with several ordinary weaknesses that appear manageable in isolation. AI makes it easier for attackers to discover how those weaknesses fit together — and act on that knowledge quickly.

CIOs do not need to fear AI. But they do need to recognize that AI is both a powerful productivity platform and a new trust boundary.

Organizations can reduce that risk by understanding their AI ecosystem, limiting unnecessary access, analyzing attack paths, segmenting critical systems and monitoring for abnormal behavior across the environment.

The future of cybersecurity will depend on how effectively enterprises can not only identify previously unknown vulnerabilities but also how well they can prevent attackers from chaining the unknown security gaps together.

In cybersecurity, engineering velocity has become a competitive advantage. Threats and vulnerabilities evolve quickly, customer security needs keep changing and organizations that respond faster are more likely to stay ahead. Across the engineering organizations I have led in cybersecurity, SaaS, mobility and insurance, I have seen how lengthy development cycles and unnecessary waiting make it harder for teams to keep pace.

Tooling can help, although in my experience it is rarely what makes the biggest difference. The pattern that consistently cut release cycles from weeks to days was giving teams end-to-end ownership of their services, including development, QA, operations and on-call responsibilities. Once the people writing the code carry the consequences of it in production, they invest in the automation, testing and observability that make frequent releases safe.

Look first at where work waits

In almost every organization I have assessed, the time spent actively working on a change is a small fraction of the time it takes to reach production. Work waits for review, for a test environment, for a decision or for another team’s dependency. That is why, when an organization tells me it needs to move faster, one of the first things I look at is where the work is waiting.

At one company I worked with, lead time on paper looked reasonable, but the gap between “code complete” and “in production” averaged around eleven days. The cause was a single shared staging environment that every team queued for, and we found it because we started measuring the wait time between stages rather than the work time inside them. Moving to ephemeral, per-change environments removed most of it, and it cost far less than the reorganization we had been considering.

In my experience, decision latency is another under-diagnosed constraint in engineering organizations. At one company where I was involved in modernizing a legacy platform, we cut deployment times by roughly 60%, with the biggest improvement coming when we retired the weekly release approval meeting and let teams ship behind feature flags. The engineering work had been ready for months, and decision latency was the bottleneck.

That experience is why I count approvals when I look at an engineering organization. I want to understand how many people must agree before a change reaches customers and what those approval steps are achieving. Once unnecessary waiting is removed, practices such as trunk-based development, automated testing that you trust, small changes and decoupling deployment from release can have a much greater effect.

Cybersecurity adds real pressure on both sides because the constraints are heavier, including audit evidence, customer security reviews, tenant isolation and the potential blast radius of a bad change. The urgency is also greater because when a new technique or vulnerability appears, customers expect products and content to reflect it within days. That combination makes engineering velocity part of how a cybersecurity organization competes.

For CIOs and CTOs, the starting point is quite practical. Map the path from idea to production and measure the time between steps, rather than focusing only on the time spent doing the work. In many of the organizations I have worked with, this has exposed problems that were far less expensive to fix than expected.

Give teams ownership and set clear guardrails

Across the organizations I have led, clear ownership has been essential to moving quickly. In practice, that means every service has a named team accountable for it in production, with the  authority to make decisions about its internal architecture, libraries, testing approach, sequencing and when to deploy.

Once the people writing the code also carry the consequences of it in production, they have a direct reason to invest in the automation, testing and observability that make frequent releases safe. This is one of the reasons I believe production ownership matters so much when an organization is trying to increase engineering velocity.

Cybersecurity still requires clear boundaries, and I keep a small set of areas non-negotiable and centrally owned. These include identity and access, data classification and handling, tenant isolation, contracts between services and anything carrying a compliance obligation. That list should be short enough that every engineer can recite it.

The mechanism matters as much as the policy. I prefer guardrails that are built into the way teams already work, including pipelines with security scanning, infrastructure modules that are secure by default and templates that make the compliant path easy to follow.

When deciding how much process a particular change needs, I start by looking at how reversible it is. I also consider the potential blast radius, whether the change touches identity, tenant isolation or customer data, and whether we would see a failure before it became visible to a customer. In cybersecurity, those factors can determine how quickly a change can responsibly move.

I saw this work with a new discovery and recommendation surface in a learning product. We shipped three variants behind flags to a small percentage of traffic and killed two of them within a fortnight. The cost of being wrong was a mediocre experience for a few hundred users for a few days, and the change was fully reversible.

Authentication and multi-tenant isolation require more care because mistakes in those areas can result in a breach. In the organizations I have led, that kind of work gets threat modelling, design review, a staged rollout and a written rollback plan before implementation proceeds. Taking additional time makes sense when the potential impact is that high.

Reversibility and blast radius help teams decide how much process a change needs. This allows teams to increase engineering velocity while maintaining the quality and trust customers expect.

Measure whether faster delivery is producing better outcomes

I never look at speed on its own. Throughput measures such as deployment frequency and lead time for change only mean something next to stability measures such as change failure rate and time to restore. If throughput rises while failure rate and restore time hold or improve, the system is genuinely getting better.

The DORA research program has had the most influence on how I think about this. Its research over the years has reinforced the connection between the practices that allow teams to deploy frequently and those that help them operate reliable systems. The 2025 State of AI-assisted Software Development report sharpened that thinking further by describing AI as an amplifier of the strengths and weaknesses already present in an organization.

That finding matches what I see in engineering organizations today, and it reflects a broader challenge around why faster coding does not necessarily translate into faster delivery. AI accelerates the writing of software. An organization still needs the platform, testing, ownership and delivery practices required to absorb that additional change.

This is why I am also cautious about AI code-acceptance rates as a measure of engineering productivity. Story points, sprint velocity, lines of code and pull request counts can be equally misleading when used in isolation because they measure activity and can easily become targets themselves. Individual developer dashboards can be especially damaging because they encourage people to protect their numbers, while much of the value I have seen engineering teams create comes from how people work together.

The SPACE framework developed by Nicole Forsgren, Margaret-Anne Storey and their co-authors is a useful corrective to single-metric thinking about developer productivity. It considers satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. That multidimensional view is much closer to how I have seen productive engineering organizations actually work.

Beyond throughput and stability, there are two outcome signals. The first is the time from a customer or threat signal to a shipped change because that is the number the business actually feels. In cybersecurity, a new threat, vulnerability or customer security requirement can create an immediate need to respond. The second is whether the outcomes we expected the work to influence have actually changed. Shipping more of the wrong thing faster is still the most expensive form of velocity.

For CIOs and CTOs looking to increase engineering velocity, my advice is to look first at where work waits. Map the path from idea to production and measure the time between steps. Buying tooling before removing those queues can simply automate the wait, and individual speed targets can make teamwork harder.

I would also protect the investments that make speed sustainable, including testing, observability and production ownership, and avoid starting with a reorganization. In my experience, a reorganization is an expensive response to what is often a queueing problem, and it can reset the trust an organization needs to move quickly.

Engineering velocity in cybersecurity comes from reducing unnecessary waiting, giving teams clear ownership, applying governance according to risk and measuring whether faster delivery is producing better outcomes. When those conditions are in place, engineering teams are better able to respond to new threats and changing customer needs while maintaining the quality and trust customers expect.

OpenAI published a detailed list of priorities and principles on Tuesday designed to govern its third-party model assessors, a list that industry observers agreed was a good one. But they also stressed that it lacked any enforceable controls to truly maintain safety.

If the goal is to encourage enterprise CIOs to trust OpenAI more, it won’t help, they said, but most doubted that this was OpenAI’s objective. Its more probable aim is to use the list to work out an arrangement with competitors and regulators so that enforcement is made more palatable, under the theory that it is open to stricter enforcement, but only if all of its key rivals are locked into identical restrictions.

The OpenAI post said, “OpenAI is committed to supporting independent assessments with deep levels of access across training, evaluation and deployment. That access should enable assessors to challenge our assumptions, identify risks we may have missed, and reach their own conclusions about the effectiveness of our safeguards.”

It added: “Third party assessments are most useful when they address specific, consequential questions: Does the evidence support a lab’s safety case and safety claims? Do evaluations adequately test the risks they are intended to measure? Do safeguards work under realistic conditions?”

Nothing about enforcement

Pieter Arntz, a malware intelligence researcher at Malwarebytes, said that giving third parties rules for engagement is certainly a good thing, but the implication behind such rules is that they are somehow enforceable. And the document says nothing about that enforcement process.

“It sets some useful expectations for independence and rigor, but it does not itself compel OpenAI to submit to a particular scope, publish adverse findings, or change deployment decisions,” he pointed out. “Its credibility will depend on the terms of individual assessments, and what outsiders are allowed to see. Its value therefore hinges on whether OpenAI accepts genuinely inconvenient scrutiny, and whether results, redactions, remediation, and deployment decisions can be independently checked.”

Valence Howden, advisory fellow at Info-Tech Research Group, agreed that the lack of enforceability makes the rules close to pointless. 

The document “doesn’t impose any requirements on OpenAI, and I would have been surprised if it did, because their motivations are not as clear-cut as they’re stating,” he said. “They also haven’t really identified what they will do based on the assessments, once they are conducted. OpenAI retains control over scope in that [OpenAI] must agree with it, limiting where assessors can go. They retain the ability to determine the appropriate level of access, which still allows them to filter what’s provided, impeding the gathering of direct evidence in those cases they define as material or classified. It also allows them to control much of the reporting and redact portions.”

Howden said the net impact is that “it’s good for determining what should be assessed, but considerably weaker on true clarity and approaches for how this is done.”

But Jason Andersen, principal analyst at Moor Insights & Strategy, offered a different perspective, although he reached the same conclusions as Howden and Arntz.

“It’s not an act of good faith to not empower these evaluators,” he said, but at the same time, CIOs need to understand the split personality of OpenAI today.

“It’s a classic problem with OpenAI because they are a split brain company, with the commercial side and the original mission side,” he pointed out. “Those two teams have not aligned very well over the past two years. It looks like it started with the original mission team, but then commercial interests took over that document and turned it into legalese.”

‘A principle instead of an excuse’

Frank Dickson, principal analyst at Dickson Research, concluded from the post that OpenAI “seems proactive in highlighting the threats posed by AI, but hesitant to accept accountability or take real action. This is a code of conduct for the assessors, not for OpenAI. The gap between the two is the whole story.”

He delved into the details of the document and was not happy. He pointed out, for example, that third-party assessor access was “granted within the bounds of legal, security, and IP constraints. That is a company deciding the scope of its own scrutiny.”

He also noted that the document specified that “publication happens after labs get a reasonable period to remediate issues. That is the same grace-period logic that just got Google criticized for sitting on the Gemini hacking disclosure for seven weeks, now written down as a principle instead of an excuse.”

Just the beginning

However, Samantha Gloede, global head of risk services at KPMG, said that she sees the document as the beginning of the process, and it should be evaluated accordingly.

“I believe the conversation will increasingly shift from assessment to accountability,” Gloede said. “Independent testing is important, but long-term trust depends on how organizations respond when material risks are identified. Stakeholders will want confidence not only that issues can be found, but that corrective actions are taken, independently validated and reflected in governance and deployment decisions. The next evolution of AI assurance will be demonstrating that accountability with the same rigor used to assess risk in the first place.”

Edna Conway, executive advisor at consulting firm Acceligence, agreed, noting that the substance of this effort will only become clear in the next phase. 

“The next step is making the lab accountable to the assessment process itself. Who determines when an assessment is required? ” she asked. “How much access is sufficient? What happens when the assessor and lab disagree about scope? Who sees a critical finding? Embracing independence is essential, as third-party assessments are genuinely valuable only when the assessor can ask uncomfortable questions, get sufficient access to answer them, follow evidence outside the original hypothesis when necessary, and report conclusions without commercial or organizational pressure shaping the outcome.”

Every acquisition is different, but the challenges facing physical security teams are often the same. As discussed in Aligning roadmaps for acquisitional growth, successful integration depends on aligning budget, technology, people and culture while ensuring security has a seat at the table throughout the acquisition process. The priorities, however, will vary depending on where your organization is in its acquisition journey.

Whether you’re preparing for future growth, actively integrating a newly acquired company or managing acquisitions as an ongoing part of your business strategy, security leaders must adapt their planning to the situation at hand. The following three scenarios outline practical considerations and planning tips to help guide your approach.

Three scenarios

Let’s game out three common scenarios regarding physical security at acquiring companies. Do any of these match a scenario your business is facing? If so, read on to find out some advice for each one.

1. FUTURE-PROOF: We plan to acquire. What can we do now?

If you think M&A changes might be on your company’s horizon, but no target company has yet been named, proactive thinking is your key to warding off messy future challenges. Beyond ensuring security is part of the M&A committee at your company, here are some other best practices for being prepared.

Start where you are

It’s never too soon to get started. Clarify risk profiles so they can be compared sensibly to those of any company you’re acquiring. Sketch out rough plans for various M&A models: What are the special considerations if we acquire a small company versus a larger one? What’s our plan if the rumors that we’re acquiring Company X are true? Having this work done and in your back pocket gives you and your team peace of mind and a head start whenever an acquisition is announced.

Plan ahead, especially budget-wise

Do your best to pre-allocate funds for likely integration activities, including systems migrations, retraining, change management and travel. Standardize core platforms and reduce or simplify as much as possible so that when the time comes, your technology is well positioned to either meld with or supersede that of the company you’re acquiring. Use your M&A models to start attaching preliminary pricing to the various systems integration scenarios you might encounter. Identify any compliance expectations pertaining to the integration time frame.

Modularize program elements

Picture a future moment when you’re faced with integrating operations across two disparate security teams, and then rewind the tape to where you are now. What’s the best possible structure for your security programs for ease of transition? Adjust your processes and team structures accordingly, and use an updated organizational chart to create role-mapping templates for each job position. Having apples-to-apples comparisons will help streamline your integration efforts.

2. UNDERWAY: Whoa! We’re acquiring. What’s the plan?

If your company has identified a target company it plans to acquire, be ready to participate in a security capacity as soon as possible. Apply the future-proofing tips from the first scenario, and in addition, take first steps toward making sense of mismatched systems and processes to ensure a smooth transition.

Keep steady communication

Stick close to the M&A committee, speak up often and be ready with physical security risk data, questions and specific needs. You’ll often face a number of important decisions, both as a team and as a company, and these decisions generally can’t be made by consensus due to the fast pace at which most acquisitions proceed. The sooner you can get buy-in for what you need, the faster you can make decisions that positively impact security outcomes.

Identify SMEs

Before the journey to a blended security team and roadmap gets underway, think about who will be the crucial players in this transition — system administrators, investigators and other physical security specialists — and build checklists of the acquisition-related tasks they’ll be expected to perform. This includes people in your company as well as in the one you’re acquiring, as soon as you can find out who they are.

Audit your current environment

If you haven’t recently produced a full inventory of your security assets, now is the time to get started. Build a catalog of your current-state architecture, including physical locations, vintages and versions, health and availability, and performance. Have this data ready to overlay with the acquired company’s environment details so integration strategies can proceed from accurate accounting.

3. PERPETUAL: We’re always acquiring. What can we do better?

At some large companies, acquisitional change is an ongoing reality, and perpetual acquisition leads to continually migrating physical security systems. Depending on the maturity and visibility of your security program, you can strengthen your participation in this process by seeking ways to help the value of your unique contribution stand out.

Adapt as you roll along

With ongoing acquisition cycles, you’re committed to running your security program in a constant state of flux, operating a diversity of technologies. This makes it unlikely—often unrealistic—to ever achieve true standardization across your enterprise. Instead, tailor your systems administration, monitoring and maintenance approaches to fit the reality of ever-shifting ground. Consider enhancing your program to include a dedicated M&A function where people and resources are tasked with managing constant change.

Maintain a reliable security backbone

Even as you make constant changes to security programs from acquisition to acquisition, an operable infrastructure must remain intact. Make it an ongoing priority to harmonize incident and emergency response plans every step of the way, with clear responsibilities, reporting structures and escalation paths so operations don’t break down during transition.

Double down on visibility

Security teams gain traction, efficiency and credibility during acquisitions when they are part of the core team managing acquisitional change. Make sure your security leaders are part of this team, able to add security input to vital budget and scheduling decisions, and consulted throughout the acquisition process, from early pre-announcement to post-M&A change management.

Develop security messaging

Every time your company acquires another, it’s important that everyone clearly understands what your team does and the value it brings. This is an opportunity to demonstrate thought leadership and lead conversations around physical security. Have clear, concise messaging that defines your mission, so time isn’t lost to misunderstandings as decisions are made. The more prepared and consistent you are as a security team, the further your input will travel.

Commit to timelines

Part of demonstrating security leadership during an acquisition is sharing clear, realistic timeframes for integration. Others on the M&A committee aren’t always familiar with the nuances of physical security or aware of the unique risks, opportunities and dependencies involved. As you communicate these considerations, provide realistic expectations for how long the security system and cultural integration will take.

Conclusion

Whether your organization is preparing for its first acquisition or integrating new companies as a regular part of doing business, physical security has an important role to play in the success of every transaction. Organizations that involve security early, establish clear priorities and build flexible roadmaps are better positioned to reduce risk, maintain operational continuity and create a stronger, more unified security program.

While every acquisition presents unique challenges, a thoughtful approach to planning, communication and integration can help security teams navigate change with confidence and support the long-term success of the organization.

Organizations today are not short of data, particularly in the domain of cyber. What many lack is a timely, trusted assessment that can help leaders act with greater confidence.

When a cyber incident begins, the technical questions surface first. What happened? Which systems are affected? Is the activity contained? But the questions that often shape the outcome are rarely technical alone. Who is behind the activity? What are they trying to achieve? Is this an isolated event or part of a broader campaign? Which customers, suppliers, assets or services are exposed? Is there a sanction, legal, regulatory or reputational dimension? And what is a proportionate immediate response while the facts are still incomplete?

This is why cyber is, in a meaningful sense, as much a human decision-making problem as a technological one. The OECD argues that digital security risk should be integrated into broader decision-making, rather than treated only as a technical issue. Tools can detect signals, spot patterns, correlate events and flag anomalies, but it takes people to decide what those signals mean, when to escalate, which trade-offs matter and what action the organization should take. In Moody’s recent whitepaper on supporting decision dominance through financial, corporate and trade intelligence, we make the case that the decisive moments in a cyber incident belong not only to systems, but to judgement.

That matters for CIOs and other technology decision-makers, because theirs is one of the most demanding decision environments in the enterprise. Reporting lines and structures vary by organization, but common themes tend to recur: technical complexity, compressed timelines, uncertain attribution and fragmented responsibility. Security teams may see indicators before they understand intent. Legal teams may need to assess obligations before the full scope of an incident is known. Communications teams often must prepare for scrutiny while operations are still working through containment. Business leaders may first need to decide when a decision must be made, then whether to pause a service, isolate a supplier, notify a regulator, issue a public statement or accept some temporary disruption to prevent greater harm.

The result can be a gap between signal and action, at a time when many organizations are experiencing a growing volume of cyber signals and alerts. Organizations commonly track mean time to detect and respond. But a less visible but equally consequential metric is decision latency: the time it takes to move from a technical signal to a shared understanding of what matters, and a decision about what to do. An organization can identify a threat quickly and still act too slowly if it cannot interpret the signal, convene the relevant stakeholders or agree on a proportionate response. The challenge is not simply speed — decisions made quickly but poorly can amplify harm. It is reducing decision latency without sacrificing judgement. This urgency is not theoretical and shouldn’t simply be admired. In her 2026 GCHQ Annual Lecture at Bletchley Park, Director Anne Keast-Butler described “a moment of consequence” shaped by the radical uncertainty. Her wider point is key for CIOs and their peers across the board: cyber security is a critical priority, and resilience depends on the ability to act with urgency, judgement and trusted partnerships.

From signal to context

Technical signals tend to become more useful when connected to wider context. A malicious domain, an unusual login, a compromised account or malware signature may tell a security team that something is happening. On its own, that signal rarely tells an executive what the organization should do next. Context reframes the question from “what does this indicator mean?” to “what decision should we make?”

That context can take several forms. Payment flows may provide additional context regarding the financial networks associated with an event or risk scenario. Ownership structures can help identify relationships between suppliers, counterparties or entities that may merit further review. Sanctions exposure may change the legal and compliance implications of a response. Adverse media may provide indicators of potential reputational or integrity concerns. Corporate linkages may reveal that what looks like a narrow technical event is in fact connected to a wider network of actors, assets or interests.

None of this removes uncertainty altogether, and no decision-maker should wait for perfect information before acting. What broader context does is improve the conditions under which judgement is exercised. Two incidents may look similar at the technical level but demand different leadership responses. One may be opportunistic criminal activity with limited broader consequence. Another may involve connections to a sanctioned entity, an organized crime network, a critical supplier or a state-linked ecosystem. The signal may look similar, but the appropriate response is not.

A cross-discipline exercise

This distinction matters because cyber response is often not contained within the security function, especially in a learning organization. A serious incident typically draws in teams from across multiple disciplines, such as security, IT, legal, risk, compliance, finance, procurement, communications and business operations. It may also involve external parties such as law enforcement, intelligence agencies, regulators, financial institutions, infrastructure operators and key suppliers. The CIO will not own every lever in this environment, and organizational structure will influence how close to the centre of the systems they sit, dependencies and information flows that affect the organization’s ability to respond effectively. Is the CIO supported or supporting during an incident? What leeway is afforded the CIO to act when required?

A common challenge in cyber response is not the absence of technical capability, but the absence, or fragility, of a shared decision model. Teams will have data, dashboards and incident playbooks in place, but still lack clarity on who decides, what information is needed, which trade-offs are acceptable and how quickly business context can be brought to bear. Ensuring a common operating picture — one that gives the leadership team a shared understanding of the same facts — tends to be a differentiator between organizations that respond coherently and those that do not.

For CIOs and CEOs, this is an organizational design problem as much as a technology one. Experience suggests that a cyber strategy that stands alone may be less effective than one integrated into the organization’s broader strategy from the outset. Cyber maturity should not be judged only by the number of controls deployed, alerts processed or systems monitored, but also by the quality of the decisions an organization can make under pressure. Using scenarios to test decision making can help refine organizational design, highlight blockers that may emerge at critical times, and improve leaders’ understanding of the potential consequences of poor decision making. That wider coordination challenge is reflected in CISA’s incident response guidance, which treats serious cyber incidents as events requiring coordination across multiple stakeholders.

Where integrated intelligence adds value

This is where integrated intelligence has a role to play. Its value lies less in the sheer volume of information it provides — most organizations already have more data than they can absorb — and more in its ability to help prioritize, separating signal from noise. It can help distinguish activity that is technically interesting from activity that may be strategically material. Used well, it can help identify enabling networks associated with an attack, inform disruption options and help focus scarce defensive resources on the assets, relationships and dependencies most likely to matter.

The aim is not to know everything. It is to develop sufficient understanding of the most relevant factors early enough to support timely actions while meaningful response options remain available.

CIOs can make this practical by asking five questions:

1. Which cyber decisions must be made in the first moments, the first hour, first day and first week of a serious incident?
2. Who is authorized to make them, what is their availability 24/7 and who deputizes in their absence?
3. Can technical indicators be linked quickly to business impact, financial exposure, legal risk, supplier dependency and external context?
4. Can security teams escalate without creating unnecessary alarm?
5. Can the CEO and board be briefed in decision-ready language, with recommendations rather than technical detail alone?

These questions move the conversation from reporting to leadership, and they reflect the human reality of cyber defence. Employees, analysts, managers and executives are asked to make repeated judgement calls under uncertainty, often with too much noise and too little time. Attackers are often well placed to exploit that reality; resilient organizations tend to design around it

Beyond visibility

Cybersecurity has spent years improving visibility, and that work remains essential. But visibility alone does not create resilience. The next challenge is decision quality.

For CIOs, the strategic shift is that cyber signals become most valuable when connected to real-world consequences: financial, operational, legal, reputational and geopolitical. In a fast-moving incident, the critical question is rarely whether the organization has more data. It is whether leaders can understand what matters, decide what to do and act while meaningful response options remain available.

The organizations that are often most effective in this environment are not necessarily those with the most dashboards. They are often those that have worked to reduce decision latency without sacrificing judgement, often through rehearsal, scenario testing and learning from gaps identified during those exercises. In an environment shaped by ambiguity, compressed timelines and interconnected risk, the ability to make better decisions faster may become one of the defining measures of not just cyber resilience, but of leadership itself.

Companies grow in many ways, and physical security must keep pace. Sometimes growth occurs naturally through the evolution of internal business programs, but other times one company grows by acquiring another one, and it’s often a company that’s very different from the one that’s doing the acquiring. Growth is exciting, but with growth through acquisition, security teams face challenges around integrating two sets of dissimilar systems, processes, org charts and security cultures. These planning tips should help keep you agile and prepared when your security team encounters acquisitional growth.

Converging to an integrated roadmap

When one company acquires another, there’s an inevitable mismatch between security programs and plans. Company A might have mature processes but outdated systems; Company B might have recent tech but few processes for integrating its use. Or the companies might have different deployment and application philosophies. Sometimes the company being acquired has no formal physical security program at all.

The security culture at each company can also clash: one uses phone-based mobile credentials, while the other uses proximity access cards; one is rigorous about securing its IP due to strict regulations, while the other can historically afford to be more casual. These disconnects intensify when the acquired company’s people aren’t motivated to adopt the policies and practices of their acquirer.

Guess what? Very soon, they’ll all need to play together as one organization. And if one or both of the companies has an existing security technology roadmap, they each face inheriting various aspects of the other’s strategy. For all plans to work together and operational continuity to be preserved throughout the change, security leaders must find some way to blend the two companies’ strategies and cultures to yield an integrated plan for common platforms, activities and standards across the newly unified team.

Elevating security visibility

For most of us, corporate mergers and acquisitions (M&A) seem to happen fast — sometimes without warning. The decision to merge with or acquire another company is typically made in corporate boardrooms, beyond the consideration or awareness of individual departments. As senior executives meet to discuss fine print and calculate bottom lines, they don’t always account for the true costs of merging teams, resources and processes at the operations level, including IT, facilities management and security.

During acquisitions, then, security needs to play a role in shaping change, not just executing it. The number one way to accomplish this is to identify the committee in your company that manages M&A-related changes and do what you can to make sure security is on it. With security leaders adding their voice, you’ll face fewer roadblocks and misfires as acquisitions proceed.

As due diligence proceeds in the wake of an acquisition announcement, it’s up to the security team to provide its own accounting and plans, so that budget and support are hopefully available to accommodate the transition. This means jockeying for visibility as decisions get made that impact the efficacy of security operations and the protection of the newly merged physical environments.

Four areas to focus on

Why does visibility matter so much for security during acquisitional due diligence?

First of all, this work matters because cost and scope assumptions regarding security systems and personnel that are made without security leadership present are doomed to be woefully inaccurate. But also, merging security programs often incurs expenses that go way beyond traditional personnel and technology costs: SME travel during due diligence and integration, retraining of personnel, support for new users and so on. The transition team might be aware of some of these costs, but security can be there early on to make a holistic case by showing cost models, gap analyses and other key roadmap elements.

Planning and positioning your new security journey along this blended route is a matter of examining each company’s current security program and finding effective ways to integrate each one with the other — including potentially sunsetting certain program elements by evaluating and selecting the ones that work best in the new organization.

Correlation must happen across four main areas — budget, technology, people and culture. Let’s take a look at some high-level guidance in each area to help you get started. Then, we’ll jump into three key scenarios to see the areas where emphasis is especially needed to achieve smooth results.

Correlation area #1: Budget and business integration

In many ways, roadmapping starts and ends with a budget. If you don’t have funding, you can’t provide security on the level you plan for. If you don’t work with your M&A committee to identify and amplify security considerations in your blended roadmap, you’ll miss the chance to get your share of budget up front. Be prepared with security budget items and ready to defend them. Need to consolidate and integrate massive security solutions at both companies? Find out now, not later, and obtain the funding you need to get it done.

At the same time, educate yourself on the relative security postures of the two companies, and seek to strengthen your overall posture where needed. Incoming business units often push back on requests for funding, and the security team at the acquiring company must be prepared. The best way is to be backed up by the right corporate policies and directives that reinforce security standards and put the burden on the acquiring company to ensure compliance. Lacking this leverage, the security team has very little leverage to get the business units to spend money.

Wielding emotional intelligence to keep productivity on track

Acquisitions are a time of heightened emotions, and morale can be sharply affected, particularly at the company being acquired. Simultaneously, the security program integrations that acquisitions entail often expose new, temporary security vulnerabilities.

The most success with positive morale and productivity occurs when both companies are intentional about understanding each other’s position. The acquiring company succeeds with diplomacy, helping the new teammates understand the WHY of certain changes rather than just steamrolling in to implement them. Including this “why” perspective will help prioritize integration activities with minimal disruption in a sometimes-fragile transition.

Meanwhile, the acquired company succeeds by finding power in its more modest position, showing up in good faith, knowing its questions will be heard and answered.

Correlation area #2: Technology and infrastructure

The nuts and bolts of merging security at two companies often come down to how you’ll overlay the tech components — primarily your access control and video surveillance platforms, but also the other systems, platforms, applications, network appliances and other technologies that support security at your sites. It also helps to have the annual costs of operating your security program ready to share, as you might discover opportunities for savings as you go along, such as lowering operating costs by eliminating redundant server resources and application licenses.

Ultimately, your goal is to retrofit and standardize systems across two — or sometimes more — environments. In the course of doing this, you’re likely to uncover gaps and mismatched elements that will take time and money to fix. In some cases, the whole platform at your company or the one you’re acquiring might be so close to end-of-life that the acquisition is actually a chance to wipe the slate clean and start over. Make sure your M&A committee understands the importance and nuances of your concerns and has visibility and clarity on your proposed approach.

Correlation area #3: People and roles

Role redundancy is usually what people fear most when they hear their company is undergoing M&A. The axe can fall pretty hard in some acquisitions, depending on how similar the roles and procedures are in each environment. Security is no exception. As soon as you can, you’ll want to carefully document teams, roles, duties and job descriptions at both companies to check for overlaps and gaps.

But don’t make assumptions too fast. You won’t know exactly how many people are needed until you’re crystal clear on the direction your new roadmap is taking. In some cases, so-called redundant personnel can be retrained, reassigned or even promoted based on revisions you make to integrate operations.

Use your voice on the M&A committee to make your personnel expectations clear. No matter the outcome, you’ll benefit from having a clear sense of each company’s security team and how their methods of providing security services compare.

Correlation area #4: Culture

Security culture is a vital consideration for acclimating newly merged companies to one another. The characteristics of a company’s culture drive the way it does business, and when one company acquires another, those cultures have the potential to clash.

Some large companies have been so stung by this reality they’ve made cultural association a deciding factor over others in whether to acquire a company or to alternatively continue growing some other way.

At companies that acquire or are acquired, these culture clashes can impact a physical security program in various ways. Users at smaller companies acquired by larger ones sometimes feel like “Big Brother” is watching them, whereas they formerly operated with less electronic oversight. If the security team at an acquired company has less sophisticated platforms and processes, they can feel overwhelmed by the need to upgrade both and adjust their approach. Change management is essential for addressing these issues and providing a unified security culture at the resulting merged company that everyone feels a part of.

Navigating security culture differences

Acquired companies often feel bombarded with integration requirements, including many that don’t match up with the security culture they’re accustomed to.

To help ease these differences, enable the business, and reduce the stress of change, both companies’ integration teams should ensure security leadership from both sides is engaged, not just the acquiring company, while helping the security team itself adjust to the increased risks it often faces as part of becoming a larger brand or differently focused operation.

Preparing for the scenarios ahead

Budget, technology, people and culture provide the foundation for aligning security programs during acquisitional growth. However, the way these areas are addressed will depend on where the organization is in the acquisition process. A company preparing for possible growth will face different priorities than one responding to an acquisition already underway or managing acquisitions as an ongoing part of its business.