Knowing where a security problem exists is only the beginning. Organisations also need to understand its significance, decide what to do and give somebody responsibility for completing the work.
That challenge connected many of the second-day sessions attended by Integrity360’s CTO Richard Ford and Director of Product Management Brian Martin at Gartner’s Security and Risk Management Summit. Discussions covered AI governance, Continuous Threat Exposure Management (CTEM), software development and automated security operations.
Across these areas, the same dependencies emerged: trustworthy information, business context and clear ownership.
Richard’s sessions examined how AI affects applications, employee tools, identities and software delivery. Assessing these risks requires an understanding of how AI changes the speed, reach and potential consequences of existing activities.
A narrowly defined assistant presents different requirements from an agent authorised to pursue a broad goal across several systems. Controls should reflect the data involved, the permissions granted and the impact of an incorrect or unauthorised action.
Governance therefore needs to cover AI the organisation buys, builds and uses. Cybersecurity, technology, data, privacy, legal and business teams all have responsibilities, with named owners for decisions and outcomes.
A self-reported register is a useful starting point, but it may leave gaps. Technical discovery across applications, endpoints, APIs, identities and network activity can provide a more complete picture. That inventory should inform threat modelling so that controls reflect how each system actually operates.
CTEM helps organisations identify, prioritise and validate exposures, then coordinate action to reduce them. Its value depends on findings progressing into practical changes.
Brian’s sessions highlighted mobilisation as a persistent challenge. Teams may agree that an exposure matters while still lacking a clear owner, an acceptable remediation route or the authority to schedule the work.
Successful mobilisation requires those barriers to be resolved. Someone must accept responsibility, the proposed response must be workable and the organisation must verify that the exposure has been reduced.
Brian also highlighted the distinction between validation and post-remediation verification. Validation establishes whether a prioritised exposure is exploitable and consequential before mobilisation. Post-remediation verification checks whether the chosen response worked.
Both are necessary, but keeping their purposes clear helps teams apply the right evidence at the right stage.
The discussions on threat exposure debt challenged reliance on vulnerability counts. The number of findings says little about which weaknesses create meaningful attack opportunities.
Reachability, exploitability, asset importance and compensating controls provide a stronger basis for prioritisation. Third-party dependencies also need consideration where a supplier’s weakness could create direct organisational exposure.
A Bitsight session explored how AI-assisted discovery could shorten the time available to assess and address weaknesses. The practical response is better visibility and a shorter path from validated evidence to action.
That context should reach the security operations centre (SOC). An alert affecting a reachable, business-critical system deserves a different response from the same activity on an isolated test asset.
Richard and Brian both attended Mark Horvath’s session on software development in the age of AI. Coding agents can increase the pace of delivery, making periodic security reviews insufficient on their own.
Approved libraries, hardened templates, secure configurations and routine checks can establish safer foundations within the development environment. These measures help developers produce more consistent results without having to resolve every security requirement independently.
Applications using AI also need testing for prompt injection, unsafe tool use, information leakage and manipulation of retrieved content or memory. These checks complement established application, API and supply-chain security.
Citizen-developed and “vibe-coded” applications make ownership especially important. Code can appear to work while containing weaknesses its creator does not recognise. Human owners remain accountable for testing, release decisions and maintenance, even when AI contributes much of the implementation.
Richard’s Vectra session examined a fundamental limitation of the agentic SOC: automated investigation cannot compensate for unreliable input.
Agents need accurate telemetry and an understanding of the people, devices, workloads and services involved. Asset criticality, exposure information and behavioural history help determine why an event matters and what response is appropriate.
Poor context can produce confident conclusions that lack adequate evidence. Improving these foundations should therefore precede decisions to grant agents greater response authority.
The quality of automated decisions also requires ongoing review. Tuning remains necessary as environments change, with feedback from analysts helping identify errors and refine the system’s behaviour.
Richard’s post-quantum session focused on the practical work involved in migration, including discovery, supplier dependencies and hardware replacement cycles.
A focused cryptographic inventory should establish where relevant algorithms and keys are used, what information they protect and how long that information must remain confidential.
Planning also needs to account for performance and implementation. Systems may depend on hardware designed for existing algorithms, while migration options may be controlled by vendors or device manufacturers.
Understanding these dependencies allows organisations to align preparation with infrastructure refreshes, testing programmes and budgets.
Caroline Webb’s keynote, attended by Brian, provided a human perspective on the pressure for faster decisions. Judgement, motivation and coordination remain essential as automation takes on more routine work.
This applies directly to CTEM and AI adoption. More findings and quicker analysis achieve little when teams lack the capacity to resolve competing priorities or carry changes through.
The second day’s discussions reinforced the importance of connecting discovery with delivery. Reliable evidence identifies the problem; ownership and coordination determine whether it is addressed.
Speak to Integrity360 about using exposure management and security operations to turn findings into measurable improvements.
Next in the series: Day three examines detection engineering, agent permissions and the evidence needed to demonstrate security outcomes.
Frequently Asked Questions
What Is the Difference Between CTEM Validation and Verification?
Validation assesses whether a prioritised exposure is exploitable and consequential before action is taken. Post-remediation verification checks whether the response successfully reduced that exposure.
Why Does an Agentic SOC Need Business Context?
Business context helps agents assess the importance of affected systems and the potential impact of an incident or response. Telemetry alone may not reveal whether an asset supports a critical service.
Where Should Post-Quantum Planning Begin?
Begin with a focused inventory of cryptographic dependencies, protected information and confidentiality requirements. Use it to assess vendor support, hardware implications and likely migration effort.