Five Ways OSINT Can Improve Incident Response Capability

Experienced incident response teams work to structured, rehearsed procedures. Roles and responsibilities are defined, decision-makers know when they must become involved, and specialist support can be mobilised quickly. That is the ideal. In practice, organisations often discover during an incident that important capabilities sit outside the plan, that business teams and their leaders do not understand their responsibilities, or that decisions cannot be reconstructed for review afterwards.

Open-source intelligence (OSINT) is one of the capabilities most often treated as an afterthought. Used properly, it is not simply "searching the internet". It is the disciplined collection, evaluation and analysis of lawfully available information to answer a defined intelligence requirement. Integrated into incident response (IR), it can reveal external infrastructure, impersonation activity, leaked data, criminal communications, cryptocurrency movements, victim exposure and the wider narrative forming around an incident.

The goal is not to gather as much information as possible. It is to provide the incident team with timely, proportionate, and properly qualified intelligence that supports three business outcomes: minimising financial loss, limiting reputational damage, and reducing operational downtime. OSINT must therefore be governed in the same way as other incident evidence: lawful collection, clear provenance, source evaluation, secure handling, verification, retention controls and an auditable record of what the organisation decided.

This article explains five practical ways to build OSINT into the complete IR lifecycle. It uses the widely recognised phases: Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Lessons Learned. Although incidents rarely proceed in a straight line, the phases provide a useful structure for assigning responsibilities, selecting actions and measuring readiness.

The Revolut Case Study

Case Study

Recent reporting concerning Revolut illustrates why an incident may begin outside the company's technical perimeter. In September 2026, reports said criminals used a compromised Italian government email system to impersonate officials and submit apparently legitimate information requests. Revolut disclosed information relating to approximately 680 customers. The company said its systems and customer funds remained secure, notified affected customers and relevant authorities, and blocked the fraudulent address.

The reports describe identity and financial records including names, addresses, identity documents and account information. Some affected people were associated with cryptocurrency holdings, increasing the potential for targeted fraud, coercion, and physical security risks. Reporting also referred to extortion, but the claimed demand varied between sources, and Revolut said that it had received no direct ransom demand. That distinction matters. The incident team responsible should record what is confirmed, what is reported by a credible third party, what is claimed by an adversary and what remains unknown.

This was not, on the information publicly available at the time of writing, a conventional intrusion into Revolut's core systems. It was a failure of trust and verification within a compliance process. Standard email authentication could indicate that a message came from a legitimate government domain, but it could not prove that the individual using the account was authorised or that the request was genuine. The case therefore has implications not just for the security operations centre (SOC) but, on this occasion, for compliance staff, legal teams, privacy specialists, fraud teams, and customer support personnel, all of whom have a part to play.

OSINT could support such a case by mapping the external identities and accounts used by the criminals, checking whether related domains or personas appeared elsewhere, monitoring lawful public channels for leaked material and impersonation, identifying exposed victims and emerging harms, tracing publicly visible cryptocurrency activity, preserving volatile web content, and assessing public reporting for accuracy. It could also support proactive checks before an incident by identifying exposed staff details, reused identities, lookalike domains and weaknesses in external verification workflows.

The key lesson is that a message can be technically authentic yet operationally fraudulent. Organisations should independently verify sensitive requests through a trusted channel, apply dual control to high-risk disclosures, and build escalation criteria into compliance and business playbooks.

"A message can be technically authentic yet operationally fraudulent."

OSINT Across the Incident Response Lifecycle

OSINT contributes before, during and after an incident. Its value depends on the question being asked at each phase.

OSINT across the incident response lifecycle

IR phase	OSINT contribution	Management question
Preparation	Map external exposure, likely threat actors, critical suppliers, executives' and staff's digital footprints, lookalike domains, and likely public information sources. Establish lawful collection methods and escalation thresholds.	What intelligence do we need, who may collect it, and what level of exposure are we prepared to accept?
Detection and Analysis	Corroborate alerts, identify infrastructure and accounts, assess leaks and claims, establish timelines, identify affected people and grade confidence.	What has happened, how confident are we, and what harm is developing?
Containment	Find attacker-controlled domains and accounts, support blocking and takedown requests, monitor adversary migration and identify secondary targeting.	Which action most reduces immediate financial, operational and reputational harm?
Eradication	Confirm that external footholds, impersonation assets and exposed credentials are no longer usable; identify residual copies or criminal reuse.	What remains outside our environment that could restart or extend the incident?
Recovery	Monitor fraud, victim targeting, media narratives and renewed publication; support affected individuals and restore trust alongside services.	Can operations resume safely, and what continuing harm requires treatment?
Lessons Learned	Compare decisions with outcomes, update intelligence requirements, playbooks, controls, training and supplier obligations.	What must change, who owns it and by when?

The lifecycle should be treated as iterative. New public information discovered during Recovery may send the team back to Analysis or Containment. Likewise, the Lessons Learned phase should produce funded changes rather than a report that is filed and forgotten. Current NIST guidance places incident response within broader cybersecurity risk management and stresses preparation, integration and continuous improvement.

1st Way: Improve Detection and Establish the Real Scope

Internal telemetry can show what occurred inside systems the organisation can see. OSINT helps reveal what is occurring outside them. It can identify newly registered domains, fake support accounts, leaked credentials, advertised access, exposed documents, paste sites, public repositories, criminal forum discussions, social media posts, and infrastructure linked by certificates, hosting patterns, or reused identifiers.

This makes OSINT both proactive and reactive. Proactively, the organisation can establish a baseline of its external footprint, monitor high-risk brands and executives, and test what sensitive information can be found through lawful public sources. Reactively, analysts can compare new indicators against that baseline and quickly distinguish ordinary background noise from a meaningful change.

The work must begin with intelligence requirements rather than tools. Useful questions include:

Is the attacker still using infrastructure that customers, staff or suppliers may reach?
Has stolen material been published, indexed or offered for sale?
Which people, business processes or jurisdictions are exposed?
Are the same personas, wallets, email addresses or domains connected to earlier activity?
Is public discussion likely to create additional fraud, safety or reputational risk?

The Coalition of Cyber Investigators emphasises that OSINT commonly directs where investigators look and which accounts, providers, wallets, servers or domains warrant further attention. It also warns that weak or unreliable OSINT can compromise later work, making standards, provenance and verification central to professional practice.

Detection should not be confused with proof. A matching username, photograph, IP address or wallet is a lead until corroborated. Analysts should record the original source, collection time, method, relevant context and any transformation. Where content may disappear, the team should preserve it in a manner consistent with legal advice, evidential needs and platform terms rather than casually downloading or redistributing sensitive material.

"Detection should not be confused with proof."

2nd Way: Strengthen Analysis with Intelligence Grading and Decision Logs

During an incident, speed creates pressure to turn partial information into certainty. A disciplined grading system helps the team state what it knows without disguising uncertainty.

At a minimum, each material OSINT item should record:

Source reliability, based on the source's history, access and possible motivation;
Information credibility, based on corroboration, internal consistency and proximity to the event;
Confidence in the analytical judgement, expressed using agreed terms such as low, moderate or high;
Handling restrictions, including whether the material contains personal data, privileged information or content that should not be circulated widely; and
Gaps and alternative explanations that could change the assessment.

The grading scheme should be simple enough to be used under pressure and documented in the practitioner playbook. Teams may adopt an established intelligence-evaluation model or a tailored equivalent, but everyone receiving the intelligence must understand what the labels mean. Grading does not make uncertain information certain; it makes uncertainty visible and comparable.

A decision log performs a related but different function. It should record the time, decision owner, information available, options considered, applicable risk or legal constraints, decision taken, rationale, expected outcome and review point. Examples include whether to take a system offline, notify a regulator, contact a platform, warn affected individuals, engage with law enforcement, make a public statement, or refuse to engage with an extortionist.

Together, graded intelligence and a decision log create an auditable chain from observation to action. They reduce hindsight bias during Lessons Learned, help incoming shifts understand why action was taken, and enable management to revisit a decision when confidence or circumstances change. The Coalition's practical guidance similarly recommends a minimal evidence log and stresses that findings should be verified before action.

3rd Way: Make Containment and Eradication Faster and More Targeted

Containment seeks to limit damage; eradication removes the cause and residual means of harm. OSINT can support both by locating external assets that internal remediation cannot reach. These may include phishing pages, fraudulent domains, malicious advertisements, impersonation accounts, public code repositories, exposed cloud storage, attacker communication channels and cryptocurrency addresses.

The response should connect external findings to specific courses of action. A domain may need to be blocked internally, reported to a registrar and included in customer warnings. An impersonation account may require platform reporting, evidence preservation, and coordinated communications. A leaked credential may require revocation, an account review, and a broader search for reuse. A public repository containing secrets may need to be removed while the secrets are rotated and logs are checked for exploitation.

OSINT also helps test whether containment is working. If the adversary changes domains after a takedown, shifts to another platform, or republishes data via mirrors, analysts can detect the change and update controls. This is particularly important when the organisation's operational environment spans cloud services, suppliers and customer-facing channels.

Actions should be proportionate to the company's risk appetite and infrastructure. A manufacturer with safety-critical operational technology, a bank processing real-time payments, and a professional services firm holding confidential client files will not make the same containment choices. The technical team should define the consequences of isolation or shutdown; business owners should define service criticality and tolerable downtime; legal, privacy and compliance teams should define mandatory constraints; and an accountable executive should accept material residual risk.

No playbook should permit an analyst to take disruptive action merely because an OSINT lead appears compelling. High-impact steps require verification and defined authority. Conversely, escalation thresholds should be clear enough that frontline staff are not paralysed while harm grows.

4th Way: Reduce Financial Loss, Reputational Damage and Operational Downtime

An effective response will ultimately be measured by business harm avoided, not by the volume of indicators collected. OSINT can help the team understand three connected impact areas.

"An effective response will ultimately be measured by business harm avoided, not by the volume of indicators collected."

Financial loss. Analysts may identify fraudulent payment instructions, resale of access, victim targeting, exposed payment data or publicly visible cryptocurrency movements. Finance staff can then apply payment holds, enhanced verification, bank liaison and fraud monitoring. The objective is not to attribute every wallet or account immediately; it is to identify decisions that can prevent further loss and preserve recovery options.

Reputational damage. Public narratives form quickly and may mix accurate reporting with speculation, manipulated evidence and attacker propaganda. Communications staff need a verified, time-stamped record of what is being said, which claims are gaining reach, and which inaccuracies are causing material harm. OSINT should inform clear corrections and customer guidance, not covertly manipulate discussion. Statements must remain aligned with the decision log and the facts the organisation can responsibly disclose.

Operational downtime. Intelligence on the adversary's objectives, affected services, and ongoing external activity can help the team opt for targeted containment rather than a needlessly broad shutdown. Recovery monitoring can show whether restored services are being retargeted or whether customers and suppliers are encountering malicious copies. Business continuity and disaster recovery plans should therefore be linked to the cyber incident plan rather than treated as separate documents.

These outcomes may conflict. Restoring a service quickly can increase financial or safety risk; publishing details early can build trust but prejudice an investigation; preserving a compromised system can aid forensics but prolong disruption. The management playbook should specify who arbitrates those trade-offs, what risk thresholds apply and when the board or crisis-management team must be engaged.

5th Way: Build OSINT Into Governed Playbooks for Practitioners and Management

OSINT becomes dependable when it is designed into governance, training and exercises. Organisations need two connected levels of playbook.

Practitioner Playbooks

Practitioner playbooks translate policy into repeatable actions. They should define approved sources and tools, legal and ethical boundaries, collection and preservation steps, intelligence grading, verification requirements, handling labels, escalation thresholds, decision-log inputs and handovers to legal, privacy, fraud, communications, human resources, procurement and law enforcement.

They should also be adapted to the organisation's actual infrastructure. Collection methods and response options will differ across on-premises systems, SaaS platforms, cloud workloads, operational technology, mobile applications and supplier-managed services. Asset ownership, logging coverage, jurisdiction, data sensitivity and contractual control should determine who can act and how quickly.

Management and Business Playbooks

Management playbooks should be written for decision-makers and non-cyber personnel. They should avoid technical shorthand and state the trigger, business impact, required decision, owner, time limit, evidence needed and fallback action.

Management and business playbook responsibilities

Audience	Example trigger	Playbook responsibilities
Accountants and treasury staff	Changed bank details, urgent payment request, leaked finance records or suspected invoice fraud	Pause or recall payments, use trusted call-back verification, preserve communications, contact banking partners, quantify exposure and document approvals.
Supply chain and procurement staff	Supplier compromise, counterfeit portal, exposed credentials or disruption at a critical provider	Verify through known contacts, identify dependent services and stock, invoke contractual notification, switch to approved alternatives and track downstream impact.
Compliance and legal staff	Official-looking data request, extortion communication or publication of regulated information	Verify requester authority out of band, determine lawful basis and notification duties, preserve privilege, approve engagement boundaries and coordinate authorities.
Communications and customer teams	Public leak claim, impersonation campaign or rising media attention	Use approved facts, issue practical guidance, capture emerging harm, route vulnerable customers and avoid repeating unverified attacker claims.
Executives and board members	Threshold for crisis activation, major service interruption or material customer harm	Set priorities, accept or reject residual risk, authorise exceptional expenditure, oversee regulatory and stakeholder strategy, and confirm recovery criteria.

The two levels must use the same severity definitions, contact routes and decision authorities. Otherwise, a technically correct practitioner response can still fail because a finance team releases a payment, a supplier remains uncontacted, or a public statement contradicts the evidence.

Government playbook guidance similarly stresses standardised procedures, coordination and clearly assigned actions, while the NIST Cybersecurity Framework treats governance, roles, authorities and risk appetite as foundations for managing cyber risk. Playbooks should be exercised with the people who will actually use them, including accountants, supply chain staff and senior management - not only cyber specialists.

Apply risk appetite to roles and responsibilities

Risk appetite should shape the response before a crisis. The organisation should define tolerances for financial loss, service outage, data exposure, safety impact, legal non-compliance and reputational harm. Those tolerances become operational thresholds: when a team may block an account, when a plant or service may be isolated, when an executive must be called, when customers must be warned and when third-party specialists are activated.

A practical responsibility model should identify one accountable owner for each major decision and specify who is responsible for execution, who must be consulted and who must be informed. It should cover at least the following: incident command, technical investigation, OSINT, legal privilege, privacy, regulatory notification, business continuity, finance, supply chain, communications, customer support, human resources, and physical security.

The model must reflect the company's infrastructure and operating model. If a critical service is run by a supplier, the company needs contacts, evidence access rights, notification timeframes, and participation in exercises. If identities are managed through a cloud provider, the playbook must reflect the actions that provider supports. If operations span jurisdictions, the organisation should pre-identify local legal and regulatory advice.

Preparation should also include retainers or call-off arrangements for incident response, external counsel, communications support, identity protection, specialist OSINT and digital forensics. Contact details, authority limits and secure communication channels should be tested, not merely recorded.

A Practical Operating Model

Organisations can integrate OSINT into IR through a short implementation programme:

Define priority intelligence requirements. Start with the incidents that could cause the greatest financial, reputational or operational harm and identify the external questions the team would need answered.
Set governance. Approve lawful purposes, sources, tools, collection boundaries, retention, handling, quality standards and oversight. Align them with privacy, employment, monitoring and evidential requirements.
Assign roles. Name the OSINT lead, incident commander, decision owners and business contacts. Map authority to the real infrastructure and suppliers.
Create both levels of playbook. Build detailed practitioner procedures and concise management or business actions for finance, supply chain, compliance, communications and other relevant teams.
Adopt grading and logging. Use a common intelligence-grading scheme, an evidence log, and a decision log. Ensure every material judgement separates fact, inference, claim and unknown.
Exercise realistic scenarios. Test incidents that cross technical and business boundaries, such as a fraudulent official request, supplier compromise, executive impersonation, data leak or extortion event.
Measure outcomes. Track time to validate a lead, time to decision, time to contain external assets, avoidable loss, downtime, stakeholder impact, unresolved intelligence gaps and completion of lessons-learned actions.

Exercises should reveal friction. Can an analyst obtain approval outside business hours? Can procurement reach a critical supplier? Can finance stop payment? Can communications access a verified situation report? Can the team record and grade intelligence without creating an uncontrolled store of sensitive data? These are capability questions, not paperwork questions.

Conclusion

OSINT can materially improve incident response when it is treated as a governed intelligence capability rather than an ad hoc search function. It expands visibility beyond internal systems, improves the quality of analysis, supports targeted containment and eradication, reveals continuing harm during recovery and strengthens lessons learned.

Its value is greatest when cyber and non-cyber teams operate from connected playbooks, apply the company's risk appetite to real infrastructure, grade intelligence consistently and record why important decisions are made. The Revolut case study shows why these matters: a serious incident can exploit a trusted business process without breaching core technology, and the resulting harm can extend across privacy, fraud, reputation, customer safety and regulation.

The practical test is simple. When the next incident occurs, can the organisation identify what is happening outside its network, explain how confident it is, decide who has authority to act, and show how each action reduces financial loss, reputational damage or operational downtime? If not, you are responding without the intelligence needed to act decisively. Integrate OSINT into your response framework before the next incident.

Authored by: The Coalition of Cyber Investigators,

Paul Wright (United Kingdom) & Neal Ysart (Philippines).

The Coalition of Cyber Investigators is a collaboration between Paul Wright (United Kingdom) - Experienced Cybercrime, Intelligence (OSINT & HUMINT) and Digital Forensics Investigator; Neal Ysart (Philippines) - Elite Investigator & Strategic Risk Advisor, Ex-Big 4 Forensic Leader; and Lajos Antal (Hungary) - Highly experienced expert in cyberforensics, investigations, and cybercrime.

The Coalition unites leading experts to deliver cutting-edge research, OSINT, Investigations, & Cybercrime Advisory Services worldwide.

Our co-founders, Paul Wright and Neal Ysart, offer over 80 years of combined professional experience. Their careers span law enforcement, cyber investigations, open-source intelligence, risk management, and strategic risk advisory roles across multiple continents.

They have been instrumental in establishing foundational legal precedents and case law in cybercrime investigations and in contributing to the development of globally accepted guidance and standards for handling digital evidence. Their leadership and expertise form the foundation of the Coalition's commitment to excellence and ethical practice.

Alongside them, Lajos Antal, a founding member of our Boiler Room Investment Fraud Practice, brings deep expertise in cybercrime investigations, digital forensics, and cyber response, further strengthening our team's capabilities and reach.

The Coalition of Cyber Investigators, with decades of hands-on experience in cyber investigations and OSINT, is uniquely positioned to support organisations facing complex or high-risk investigations.

Our team's expertise is not just theoretical - it's built on years of real-world investigations, a deep understanding of the dynamic nature of digital intelligence, and a commitment to the highest evidential standards.