Guide2024-12-2014 min read

How to Build a Threat Profile: A Worked Example for Mid-Market Security Teams.

Building a threat profile sounds straightforward on paper. Define your assets, identify relevant threat actors, map their techniques, review periodically. The steps are well-known and there's no shortage of good material explaining them.

The harder part is the gap between the steps and the Monday morning. When an actual security lead sits down to build one, a lot of concrete questions show up that the steps don't quite answer. What does “identify threat actors” look like when you're running a 400-person fintech and don't have an in-house nation-state analyst? How much detail is the right amount? What do you put in front of the board? Where does the profile actually live, and who updates it when things change? Those questions are where most teams — including some I've been on — end up improvising.

This post is a worked example. It follows a fictional mid-market company — Meridian Pay, a B2B payments processor — through the end-to-end process of building a threat profile that a small security team can actually maintain. The goal is not a hundred-page document that sits on a shared drive. It's a living, operational artefact that connects what the business cares about to the detections the security team runs.

If you're looking for the theory behind any of the steps below, the CTI from the Trenches series covers it in more depth. This post is the worked example the series keeps referring back to.

What a threat profile is (and what it isn't)

A threat profile is a structured description of the threats most relevant to your organisation — the ones you should actually care about, given who you are, what you do, and what you have. It answers three questions in a form your team can act on:

Who is likely to target us, and why?
How would they do it, in terms of techniques and behaviours?
What should we defend, detect, and respond to as a result?

It is not a threat report. It's not a risk register. It's not a compliance deliverable. And it's not a list of every threat actor that exists in the world — that's a reading list, not a profile. A threat profile is deliberately narrow: the subset of threats that actually intersect with your organisation.

A good threat profile should be short enough that someone can read it in ten minutes, current enough that it reflects the last quarter, and specific enough that two different analysts would prioritise the same things when they read it. If your profile doesn't do all three, it probably isn't working yet.

Meet Meridian Pay

The worked example uses a fictional company designed to look like a lot of real ones:

Business: B2B payments processor. Handles card-present, card-not-present, and account-to-account payments for mid-market merchants.
Size: ~400 employees. Security team of 8, including 2 people with CTI responsibilities (shared with other duties).
Geography: Headquartered in London, with operational offices in Dubai and Singapore. Customers across Europe, the GCC, and South-East Asia.
Stack: Cloud-native on AWS. Kubernetes workloads. Microsoft 365 for corporate. Okta for identity. Core payments platform built in-house in Go.
Regulated under: PCI DSS, FCA in the UK, CBUAE in the UAE, MAS in Singapore, plus GDPR.

If your organisation looks nothing like this, the structure still applies — you'll just swap the details. The point is how the profile gets built, not the specific answers.

Step 1: Start with the questions, not the answers

The most common mistake in threat profiling is jumping straight to “which actors should we track?” That puts the cart roughly three kilometres ahead of the horse. The real starting point is what decisions does the organisation need your threat profile to support?

In intelligence tradecraft, those decisions are captured as Priority Intelligence Requirements (PIRs) — specific questions the business needs answered to make specific choices.PIRs are one of the most underused tools in commercial CTI, and also the one that makes everything downstream easier. If you don't have PIRs, your threat profile will drift toward whatever's in the news. If you do have them, the profile almost writes itself.

For Meridian Pay, a first-pass PIR set might look like:

PIR-1: Which threat actors or campaigns are actively targeting mid-market payments processors in Europe, the GCC, or South-East Asia?
PIR-2: What initial access techniques are succeeding against cloud-native (AWS + Kubernetes) fintech environments in the last 6 months?
PIR-3: Which vulnerabilities in our core stack (Go services, Okta, AWS services, Kubernetes) are being actively exploited in the wild?
PIR-4: What changes in the regulatory environment (FCA, CBUAE, MAS) require proactive intelligence input from the security team?
PIR-5: What fraud and payments-specific techniques (BIN attacks, refund fraud, authorised push payment fraud) are emerging against customers of similar size?

Five is enough to start. Each one maps to a real decision the business cares about — detection investment, patching priority, regulator engagement, fraud team support. A profile built on PIRs is a profile that gets read.

If you want to go deeper on writing good PIRs and mapping them to sources, the collection planning post in the CTI series walks through the process in detail.

Step 2: Define what you're actually defending

Before looking outward at threats, look inward at what matters. The point of this step is not to inventory everything — asset inventories are a different document. The point is to identify the small number of things whose compromise would genuinely change the shape of the business.

For Meridian Pay, after an honest conversation with the CFO, CTO, and Head of Compliance:

Payments processing pipeline. Any compromise that stops payments from moving is a business-ending event within days. Anything that manipulates payment instructions is worse.
Cardholder data environment (CDE). Regulatory and reputational consequences of a breach are severe, plus contractual exposure to merchants.
Privileged identity infrastructure. The Okta tenant and AWS root/organisation accounts are the keys to everything else. A breach here is effectively total.
Source code and CI/CD pipeline. The core payments platform is a competitive asset; the CI/CD pipeline is a realistic supply chain vector into production.
Customer trust. Not a system, but the asset that underwrites the commercial model. Any incident that makes the front page affects this directly.

Notice what's not on the list. HR systems, the marketing site, the office Wi-Fi. They matter. But compromise of any of them is recoverable. Compromise of the five things above is existential. That distinction is the entire point of this step.

Step 3: Map threats to categories, not names

This is the step I'd take the most care with, because the intuitive starting point leads somewhere different from where most profiles end up being useful. The natural move is to pick a set of named threat actors — APT28, Scattered Spider, LockBit — and build the profile around them. There's a case for that, and for some organisations it works. But on balance I'd suggest starting one level of abstraction above.

Threat actors come and go. Names change. Infrastructure rotates. Tooling gets sold, leaked, or re-skinned. What changes much more slowly is the category of threat and the behaviour patternsinside it. That's what the profile should be built on. Named actors become illustrative examples inside each category, not the scaffolding.

For Meridian Pay, the relevant categories are:

Financially motivated cybercrime. By far the most likely threat. Ransomware affiliates, initial access brokers, and payments-fraud crews are all in scope. Examples: ransomware groups that have historically targeted fintech and payments, plus commodity infostealer operators whose output feeds the access-broker market.
Nation-state pre-positioning.Lower likelihood, but not zero. Payments infrastructure is strategically interesting to several state actors, and the GCC presence raises the profile. The defensive implication is different from cybercrime — longer dwell time, more patience, focus on intelligence collection rather than immediate monetisation.
Hacktivism. Low likelihood in isolation, but the GCC operational footprint creates exposure whenever regional tensions rise. Usually manifests as DDoS or defacement, occasionally as symbolic data leaks.
Insider threats.Financial services consistently sees insider events — often negligent rather than malicious, but the impact can be identical. Elevated during restructuring or layoffs.

For each category, the profile should capture why it matters for this specific organisation, what the defensive implication is, and which observable behaviours to track. The framework for building those per-category profiles is covered in detail in the threat actor profiling post — this step is where it gets applied.

Step 4: Translate threats into TTPs and detections

A threat profile is only useful if it connects to what the security team actually does. The connection point is the list of techniques the team should be detecting and responding to — ideally mapped to MITRE ATT&CK so it plugs directly into detection engineering.

For Meridian Pay, the exercise looks like this. Take each threat category, list the initial access and post-access techniques most commonly observed across the reporting of the last 6–12 months, map each to an ATT&CK technique ID, and then assess current detection coverage honestly.

A simplified extract for the financially motivated category:

T1566 Phishing → T1204 User Execution → T1059 Command and Scripting Interpreter. Initial access via malicious attachments or links, leading to infostealer or loader execution. Current coverage: email filtering strong, endpoint detection partial, user reporting channel underused.
T1078 Valid Accounts (Cloud). Credential abuse of SaaS and cloud accounts via infostealer-sourced credentials. Current coverage: Okta anomaly detection present, AWS IAM anomaly detection partial, session hijack detection absent.
T1190 Exploit Public-Facing Application.Edge device and public API exploitation. Current coverage: vulnerability management runs weekly, but time-to-patch on edge devices averages 14 days — too slow for currently-exploited CVEs.
T1486 Data Encrypted for Impact → T1490 Inhibit System Recovery. Ransomware execution and backup destruction. Current coverage: immutable backups in place, but ransomware-specific tabletop exercises haven't been run in the last year.

The exercise is deliberately simple: list the techniques, map them to coverage, identify the gaps. The output is a prioritised shopping list of detection engineering work. That's the threat profile earning its keep — not as a document, but as a driver of investment decisions.

If the team has the bandwidth, the same approach applies to the other three categories (state-nexus, hacktivism, insider). For a small team, it's fine to start with the highest-likelihood category and expand over time. A partial profile that's actually used beats a complete one that never gets finished.

Step 5: Keep it alive

The hardest part of threat profiling isn't the initial build — it's what happens six months later, when other priorities have pulled attention elsewhere and the document hasn't been opened in a while. This is something I've struggled with personally, and I think most practitioners have. The build is a project with a clear end. Keeping it current is a habit, and habits are harder.

Two practices help.

The first is trip-wires. Instead of reviewing the whole profile on a fixed cadence, set up lightweight signals that automatically prompt a review when something material changes. A trip-wire might be a new CVE in one of the technologies on the profile, a significant campaign report against the sector, a regulatory change in one of the operating jurisdictions, or a major incident affecting a peer. When a trip-wire fires, the analyst's job is to ask “does this change the profile?” — and if yes, update it that day.

The second is a stakeholder feedback loop. Once per quarter, the security lead walks the current profile through a short conversation with the CTO, Head of Fraud, and Head of Compliance. Not to ask if they like it — to ask whether anything in their world has changed that should affect it. New products, new markets, new regulations, new vendors. Those conversations are where a threat profile stays connected to the business.

Both practices are covered in more depth in the intelligence lifecycle post — specifically the Direction and Feedback phases, which are the two most commonly skipped.

The finished artefact: a one-page threat profile

Here's what the actual deliverable looks like for Meridian Pay. A single page. Enough structure to be useful, little enough structure to be maintained. Adapt the sections and length to suit your own context — the point is the shape, not the exact wording.

Threat Profile: Meridian Pay
Owner: Head of Security — Last updated: Q4
1. Business context. Mid-market B2B payments processor. Cloud-native. UK, GCC, SEA footprint. PCI DSS, FCA, CBUAE, MAS, GDPR. Security team of 8. Compromise of payments pipeline, CDE, privileged identity, or CI/CD is existential.
2. Priority Intelligence Requirements.
Active threats to mid-market payments in UK, GCC, SEA
Cloud-native (AWS/K8s) initial access techniques
Exploited CVEs in Go, Okta, AWS, Kubernetes
Regulatory intelligence (FCA, CBUAE, MAS)
Payments-specific fraud techniques
3. Threat categories (prioritised).
Financially motivated cybercrime — HIGH. Ransomware affiliates, access brokers, payments fraud crews. Detection priority: phishing chain, cloud credential abuse, public-app exploitation, ransomware impact.
Nation-state pre-positioning — MEDIUM. Strategic interest in payments infrastructure, elevated by GCC footprint. Detection priority: long-dwell lateral movement, credential harvesting at scale, data staging.
Hacktivism — LOW-MEDIUM. Elevated during regional tension. Detection priority: DDoS readiness, public-facing asset integrity monitoring.
Insider — LOW, elevated during change. Detection priority: privileged access monitoring, DLP on source code and CDE, offboarding hygiene.
4. Top detection priorities this quarter.
Cloud session hijack detection (Okta + AWS)
Edge device patch time < 72h for known-exploited CVEs
CI/CD pipeline integrity monitoring
Ransomware tabletop exercise (scheduled for Q1)
5. Trip-wires. Any CVE on Okta, AWS, K8s, or Go core libraries; any ransomware campaign report against payments or fintech; any major incident at a peer processor; any FCA or CBUAE advisory.
6. Next review: On trip-wire trigger, or end of Q1 at the latest.

That's the whole thing. Six sections, one page. Specific enough that a new analyst reading it on their first day would know where to focus. Short enough that the security lead can actually keep it current. Directly connected to detection engineering through Section 4, and to the intelligence lifecycle through Sections 2 and 5.

Things I've learned the hard way

A few patterns that are easy to fall into on a first pass — I've fallen into all of them at least once, so this section is written as “things I wish I'd known earlier” rather than as corrections.

It's tempting to build the profile inside the security team.Especially on the first version, when you're not sure what to ask for yet. The risk is that the profile drifts toward technical completeness and away from business relevance. What helped me was forcing the conversation early — even a 30-minute walk-through with the CTO or a business leader on the draft tends to surface the things the security team couldn't see on its own. The PIR step especially benefits from this.

It's tempting to make the profile comprehensive. There's a natural pull toward including every threat actor that has ever touched the sector, every technique in the matrix, every possible scenario. The instinct makes sense — it feels more thorough. The tradeoff is that a very long profile gets harder to act on and harder to keep current. What I've found works better is picking a narrow version that covers the top priorities, and expanding it when the team has capacity. A partial profile that actually gets used is more valuable than a complete one that doesn't.

It's tempting to let the profile drift toward the compliance deliverable it might also need to be. Audit and regulatory asks are real, and sometimes the same artefact is being pulled in two directions at once. The question I try to ask is whether the profile changes what the team detects, patches, hunts for, or trains on. If the answer is yes, it's working as a profile. If the compliance framing starts to crowd that out, it's worth producing a separate document for the auditor and protecting the profile's operational role.

Annual reviews are easier to schedule than they are to get value from. A profile reviewed once a year is accurate for a fairly small slice of that year. The trip-wire model isn't more work overall — it's the same work, rescheduled to when it's most useful. Worth the setup cost.

Where Liberty91 fits

A lot of the work above is exactly the work a small security team struggles to find time for. Not because it's hard, but because the 80% of an analyst's day that goes to collection, filtering, and report assembly leaves little room for the 20% that actually builds and maintains artefacts like a threat profile. This is a structural challenge, not a skills problem — and it's the challenge Liberty91 was built around.

The platform takes the PIRs you define, monitors hundreds of sources against them in real time, and surfaces only what's relevant — already enriched with IOCs, ATT&CK mappings, and suggested detection logic. Trip-wires become automated. The threat profile becomes a living document the team actually consults, rather than a quarterly exercise.

The profile above took a few hours of thought to sketch out. With the right tooling, maintaining it should take minutes a week — not days.