How to Create a Collection Management Framework (CMF) and Why It’s Essential for Incident Response
Most incident response failures don’t begin with a lack of tools.
They begin with a moment, often early in an investigation, when a senior responder asks a simple question and no one in the room can answer it with confidence.
How did the attacker get in?
How long were they here?
Which systems were actually affected?
What data can we rely on to support that conclusion?
These are fundamental investigation questions, and they routinely surface uncomfortable gaps in organisations that believe they’re well prepared: environments with mature Security Information and Event Management (SIEM) platforms, endpoint tooling, cloud logging, threat intelligence feeds, and years of investment in “visibility.”
The data often exists. What’s missing is the prior decision about which evidence matters, why, and where it should come from.
This is the gap a Collection Management Framework (CMF) is designed to close.
A CMF is a governance and decision-support capability. It sits underneath incident response (IR) and determines whether your organisation can investigate with evidence you can defend or has to improvise under pressure.
This article explains what a CMF looks like in practice, where evidence assumptions usually hide, and how those gaps weaken IR, executive confidence, and defensibility.
For regulated and high-consequence organisations, evidence gaps affect operations, legal defensibility, executive decision-making, regulatory reporting, and the organisation’s ability to explain what happened.
A CMF helps ensure that when leadership asks what happened, how broadly it spread, and what evidence supports that conclusion, the response is grounded in something more reliable than assumption.
Need a clearer picture of whether your current evidence sources will support a real investigation?
If you’re unsure whether your organisation could confidently answer core investigative questions during an incident, explore our Incident Capability Validation. It’s a structured assessment designed to baseline and stress-test your broader incident response capability, including the evidence your teams rely on.
The Recurring Challenge a CMF is Meant to Solve
In real incidents, skilled responders still get stuck when the evidence they expected isn’t available.
Consider a familiar scenario: you detect an intrusion on a server hosting sensitive data. The response team is confident at first. There are Endpoint Detection and Response (EDR) agents deployed, network monitoring in place, and centralised logging. However, within hours, uncomfortable questions emerge.
Authentication logs only go back a few days.
Process creation telemetry was disabled to reduce noise or save disk space.
Network flow data exists, but only at the perimeter.
Critical administrative actions were never logged centrally.
None of these are mistakes made during the incident. They’re consequences of decisions that were never made explicitly beforehand.
In practice, organisations often operate with an implicit collection posture: logs are enabled by default, adjusted over time, shaped by tooling constraints, storage limits, and operational convenience. That posture is rarely tested against investigative reality until an incident forces the issue.
A mid-sized Asia-Pacific (APAC) manufacturer suffered a ransomware attack. During triage, the IR team requested domain controller authentication logs to understand how the attacker moved laterally. It turned out those logs weren’t centralised and were only stored locally on the host for seven days. By the time responders arrived, the necessary logs were overwritten. The team were left blind as to how credentials were compromised.
Lack of visibility prolonged the recovery effort, weakened confidence in scoping decisions, raised regulatory questions, and eroded trust among stakeholders.
At that point, collection gaps become visible, and they’re expensive to address. You can’t retroactively collect data. Assumptions collapse. Confidence erodes across the response team, executives, and the board, where leaders suddenly discover that “we have good logging” doesn’t mean “we can answer basic investigative questions.”
Frameworks like NIST Cybersecurity Framework (CSF), ISO/IEC 27035, and MITRE ATT&CK all highlight the importance of evidence collection and visibility. A CMF turns that advice into decisions your teams can test: what evidence matters, where it lives, how long it lasts, and who owns it. Without a CMF, incident response turns into a scramble to find out what data exists before analysis can begin.
What a Collection Management Framework Actually Is
A CMF is a structured way of deciding, in advance, what evidence your organisation needs to collect to investigate incidents credibly.
In practical terms, a CMF answers a single question:
When an incident occurs, what evidence do we need to collect, from where, and why?
Everything else flows from that.
A CMF documents the relationship between investigative questions and data sources. It defines which systems produce relevant evidence, what that evidence can and can’t tell you, how long it’s retained, and who’s responsible for ensuring it’s available when needed.
Treat a CMF as the decision layer beneath logging, tooling, and playbooks. It gives incident response leaders, security managers, and technical teams a shared way to decide what evidence matters, what it costs, and what operational impact they’re accepting.
Where a CMF Fits
It helps to separate a CMF from the things teams already recognise. Logging strategies decide what to collect and retain. Detection engineering decides what should alert. Playbooks describe what responders do. Incident response plans define roles and authority.
A CMF sits before all of them and tests whether the evidence those activities rely on will exist when you need it.
When teams miss these distinctions, they ignore a CMF or fold it into existing activities, leaving the underlying gap unresolved.
Why Organisations Struggle Without a CMF
The absence of a CMF is rarely deliberate. It emerges naturally from how security programs grow.
Tooling is acquired incrementally. Logging decisions are made to solve immediate problems. Storage constraints lead to compromises. Teams change. Assumptions accumulate. Over time, the organisation develops confidence in its visibility without ever testing whether that visibility aligns with investigative needs.
In my experience, the same gaps keep showing up. Teams collect data because the tool makes it easy, even when that data doesn’t answer a known investigation question. They miss the less obvious sources like administrative actions, identity changes, lateral movement, and short-lived cloud events. Then, once an incident starts, they scramble to enable logging or request data that should’ve already been available.
Tool-driven collection is often the hardest habit to spot. Tool deployment ends up dictating what data exists, even when investigations need something else. This creates a false sense of completeness and makes gaps invisible until challenged.
A CMF names those pressures early, before your team is dealing with them during a breach.
CMF as a Decision-Support Capability
The core value of a CMF is better decision-making under pressure.
IR is a sequence of decisions made under uncertainty: how to scope, when to escalate, what to contain, what to disclose, and when to conclude. Every one of those decisions depends on evidence.
A CMF improves decision-making by making evidence availability a known quantity before a crisis.
When a senior leader asks whether an incident is contained, the response team shouldn’t be debating whether the necessary telemetry exists. They should already know what evidence supports or undermines that claim, and what its limitations are.
This is particularly important for executive and legal defensibility. Your confidence comes from being able to explain how conclusions were reached, what evidence was considered, and where uncertainty remains. A CMF underpins that explanation.
What a CMF Looks Like in Operation
A mature CMF is usually maintained as a living reference. Its function matters more than its form.
At a minimum, it establishes clear collection objectives. These objectives are derived from the organisation’s risk profile, threat landscape, and business priorities. They’re expressed as investigative needs first: for example, the ability to determine whether privileged access was abused on critical systems, or to reconstruct user activity in cloud environments.
From those objectives, the CMF identifies relevant data sources. These include endpoints, servers, network infrastructure, identity systems, Software as a Service (SaaS) platforms, cloud control planes, and any other environment where meaningful evidence can reside. For each source, the CMF captures what types of questions the data can answer, and just as importantly, what it can’t.
| Incident Scenario | Required Evidence / Logs | Current Collection Status | Retention (Days) | Owner / Contact | Gap Identified | Priority |
|---|---|---|---|---|---|---|
| Ransomware | Endpoint telemetry (EDR, antivirus logs) | EDR logs collected in SIEM | 30 | Security team lead | Retention too short | High |
| Domain controller authentication logs | Local host | 7 | IT operations | No central collection | Critical | |
| Firewall traffic logs | Centralised in SIEM | 90 | Network team | Retention too short | Low | |
| Phishing / Business Email Compromise (BEC) | Email message trace and quarantine logs | Exchange Online, accessible by request | 90 | IT helpdesk | Manual retrieval only | Medium |
| Microsoft 365 audit logs (user sign-ins, mailbox rules) | Collected in Defender portal | 30 | Cloud team | Needs longer retention | High | |
| Insider Threat | File server access logs | Only local logging | 14 | Storage admin | No centralised collection | Medium |
| HR case management records | Stored separately | N/A | HR manager | No linkage to IR | Low |
Prioritisation is explicit: Some systems matter more than others, and some logs carry more investigative value. A CMF makes those judgements visible, allowing constrained resources to be directed toward evidence that supports the most consequential decisions.
Ownership is unambiguous: Every data source has a responsible party who understands its role in IR. This avoids the common situation where everyone assumes someone else is collecting or retaining a particular dataset.
Validation is continuous: Tabletop exercises, real incidents, and after-action reviews are used to test the CMF against reality. When gaps are identified, the framework is updated. This creates a feedback loop between planning and practice.
Lifecycle management ensures the CMF evolves with the organisation: New systems are added. Old ones are retired. Threats change. The CMF is reviewed accordingly so it stays current.
The work comes down to ownership, consistency, and visible trade-offs; a tool can help later.
Want to test whether your current collection assumptions hold up in practice?
Our Cybersecurity Tabletop Exercises help teams identify where evidence, logging, and decision-making assumptions break down under realistic incident conditions.
How to Build a CMF
You can start a CMF with the same approach you’d apply to building and maintaining an asset inventory.
Step 1: Identify Likely Incident Scenarios
As with most IR processes, start by focusing on the incidents or scenarios you’re most likely to face.
For many organisations, particularly in the earlier phases of maturity, this means:
- Phishing-led credential theft
- Ransomware
- Insider threats (malicious or accidental)
- Business email compromise
- Cloud / SaaS account compromise
You don’t need to plan for every possible threat; start with the top three to five that align with your business risks.
Step 2: Map Required Evidence for Each Scenario
For each incident type, ask: what data would we need to investigate and recover? Those data sources will include:
- Endpoint telemetry: EDR alerts, process execution, registry changes, event logs
- Authentication logs: Active Directory, Entra ID, Okta
- Firewall / proxy data / NetFlow / full PCAP: north-south and east-west traffic
- Cloud audit trails: AWS CloudTrail, Microsoft 365 audit logs
- Email logs: message trace, quarantine details
- Backups: integrity, last successful test restore
Mapping data like this gives analysts a clearer understanding of what to look for, where to find it, and what gaps can exist.
Step 3: Assess Existing Data Sources and Collection Capabilities
Now that you know what you need, take stock of what you’re already collecting. Be brutally honest:
- Are logs centralised or only available locally on individual devices?
- How long are they retained / what’s their retention period?
- Who has access to the data in a crisis?
- Are they searchable, or buried in flat files?
A simple spreadsheet will work: list the data source, its retention period, and where it lives. (Excel is at least the second best tool for most jobs in digital forensics.) To avoid starting from a blank page, adapt and expand your existing asset inventory with the additional information.
Step 4: Identify Gaps
Once you’ve mapped your needs to your current state, the gaps should become clearer. Common issues include:
- No endpoint telemetry beyond antivirus
- Insufficient log retention (30 days when you need 90 - 180 days minimum, ideally 12+ months)
- Cloud services without centralised logging (or any logging where a required licence isn’t in place)
- Over-reliance on a single Managed Security Service Provider (MSSP) feed with limited visibility
Clearly document any gaps you identify. That documentation becomes your evidence-based case for investment and informs your program of work or JIRA board for the next 6 to 12 months.
Document these gaps for technical improvement and defensibility. Known and accepted limitations are far easier to explain after an incident than surprises discovered in the middle of one.
Step 5: Prioritise Improvements
Not all logs are created equal. Focus on the highest-value or most volatile data sources first. Start with sources that give you the most investigative value across scenarios or disappear quickly: registry artefacts like MRU lists, deleted file metadata, memory artefacts, network connections, console buffers, open file handles, execution evidence like Windows Prefetch, and identity or authentication logs. Then work down into application-specific data and niche SaaS sources.
When operating in Industrial Control System / Operational Technology (ICS/OT) environments, consider vendor-specific data sources. Industrial networks contain several sources of data unfamiliar to IT incident responders, like Human-Machine Interface (HMI) logs, Programmable Logic Controller (PLC), and Remote Terminal Unit (RTU) telemetry, and other evidence-rich locations. Work with the operators and the relevant vendor to discover potential sources of evidence.
Note: some vendors are better than others when it comes to logging, both in terms of granularity and ease of collection, processing, and analysing log data. Expect variation.
Step 6: Review and Update Regularly
Like most incident or asset management documents, a CMF needs regular review. New applications appear, cloud services are adopted, and attacker tactics, techniques, and procedures (TTPs) evolve. Review your CMF at least annually or after specific triggers like a significant incident, a merger or acquisition, or a tabletop exercise (TTX) that reveals gaps.
How a CMF Integrates with Existing IR Structures
A CMF strengthens existing IR capabilities.
IR plans become more credible because their assumptions about evidence are grounded in documented reality.
Playbooks become more effective because they can reference known data sources your teams can actually use.
Tabletop exercises become more valuable because the collection gaps they surface feed directly into framework improvement.
Detection engineering becomes more aligned with investigation because alerts are designed with supporting evidence in mind.
Executive decision-making improves because leaders understand what happened and how confidently it can be stated.
A CMF is the connective tissue that aligns these activities around a shared understanding of evidence.
Constraints and Trade-offs are Unavoidable
No organisation can collect everything.
Budget constraints limit storage and tooling. Some environments offer limited visibility by design. Increased logging can introduce operational risk. Organisational maturity varies.
A credible CMF documents known gaps, accepted risks, and mitigation strategies so incident decisions can be defended later.
Gaps will exist. Your job is to know which ones are accepted, which ones are being fixed, and which ones are still hidden.
CMF Across the Incident Lifecycle
During preparation, your CMF shapes what’s collected and why. During response, it accelerates investigation and reduces uncertainty. During escalation, it supports confident communication. After incidents, it provides a basis for learning and improvement.
At each stage, teams without a CMF have to rediscover fundamentals they should already be applying.
Collecting Deliberately, Not Reactively
A Collection Management Framework focuses collection on the evidence your investigations actually need.
Organisations without a CMF often appear mature until they’re tested. When that test comes, the weak point is usually the evidence model beneath the tools.
A CMF provides that foundation. When incidents occur, investigations are guided by foresight, and decisions are supported by evidence.
If you want to pressure-test whether your current plans and playbooks account for real-world evidence gaps, begin with our Incident Response Plan & Playbooks: 10-Minute Quality Check.
If you want to see what data your team can and can’t access under realistic conditions, explore our Cybersecurity Tabletop Exercises.
And if you want a structured assessment of your organisation’s broader incident response capability, including the evidence required to support defensible decisions, see our Incident Capability Validation.
Your organisation should be able to answer the questions that matter most when pressure is highest.
Disclaimer: This content may have been edited or refined with assistance from AI tools. All final content, views, and recommendations are our own.