Cyber Crime Taxonomy: TLCTC+ and the #9 Distinction

The Industry Confusion about Cyber Crime

When executives say "we suffered a cyber crime," they might mean:

• $2M wire fraud via CEO impersonation call
• Ransomware attack via phishing email
• Romance scam targeting an employee
• Data breach via compromised credentials
• Sextortion through manipulation
• Account takeover leading to fraud

These are fundamentally different threats requiring different teams, different controls, and different response strategies. Yet most organizations treat them identically under the vague umbrella of "cyber crime." The TLCTC framework brings precision by keeping #9 Social Engineering as a single cause-side cluster while letting the TLCTC+ extension capture the consequence-side difference between cases that compromise an IT system and cases that don't.

The #9 Distinction: Three Case Classes Around Social Engineering

TLCTC+ defines three case classes for incidents that involve #9. They differ by whether a System Risk Event (loss of control over an IT system) and a Data Risk Event (DRE) occurred, and whether a nationally reportable Business Risk Event (BRE) needs to be recorded:

• Class A — Core Cyber Incident. The classical TLCTC chain. Example: #9 → #4 → #7 + [DRE: C]
• Class B — Hybrid Cyber-Enabled Harm. The cyber chain exists, and a downstream nationally reportable harm is also relevant. Example: #9 → #4 + [DRE: C, I] + [BRE: Account Takeover Fraud]
• Class C — Digitally Mediated Non-SRE Harm. No system is compromised. Pure manipulation produces a Business Risk Event. Example: #9 + [BRE: Romance Scam]

Case Class C: Digitally Mediated Non-SRE Harm

Definition

Pure manipulation leading directly to harm. No IT system is compromised, no Data Risk Event in the classical cyber sense. These are classical crimes executed via digital communication channels — captured in TLCTC+ as a #9 cause-side step terminated by a consequence-side + [BRE: ...] annotation.
Attack Path: #9 ||[context][@External→@Citizen]|| + [BRE: <label>]
Concrete example: #9 ||[messaging][@External→@Citizen]|| + [BRE: Romance Scam]

Examples (with TLCTC+ notation)

• CEO fraud (no system compromise): #9 + [BRE: CEO Fraud Transfer]
• Romance scam: #9 + [BRE: Romance Scam]
• Investment fraud: #9 + [BRE: Investment Scam Loss]
• Sextortion via manipulation: #9 + [BRE: Sextortion Payment]
• Fake tech-support payment (no remote access installed): #9 + [BRE: Fake Tech Support Payment]
• Induced supplier-payment diversion: #9 + [BRE: Supplier Payment Diversion]

BRE labels are a controlled vocabulary maintained at the national/regional level (NCSC/CERT). They sit on the consequence side of the Bow-Tie and are subordinate to the cause-side #9 classification.

The TLCTC Reality: Minimal Applicability

From a cyber threat perspective, only two controls apply:

1. Awareness training - Reduce success rate (never eliminate)
2. Law enforcement coordination - Remove criminals from ecosystem

That's all. You cannot change human nature. The generic vulnerability—human psychological factors (trust, fear, urgency, greed)—is inherent. It exists on both sides:

• Attacker side: Criminals exploit psychology (always have, always will)
• Target side: Humans remain susceptible (this is biology, not a technical flaw)

What About Dual Authorization, Verification, Transaction Limits?

These are not cyber threat controls. They are business process controls for liability mitigation and regulatory compliance. They apply equally whether fraud occurs via:

• Phone call (physical world)
• In-person manipulation (physical world)
• Postal mail (physical world)
• Digital communication (digital world)

These belong in Operational Risk / Fraud Prevention, not cybersecurity threat management.

The Damage & Liability and Legal Driver

This is the critical insight: For Class C, controls are driven by liability exposure and regulatory mandates, not cyber threat prevention. When an organization's product or service is the fraud vector (e.g., banking wire transfer systems, payment platforms, communication services), regulators and legal systems impose requirements:

Regulatory Examples:

• PSD2 Strong Customer Authentication (EU)
• FINMA RS 17/01 operational risk requirements (Switzerland)
• Banking transaction verification standards (global)
• Product liability standards (sector-specific)

Liability Drivers:

• Demonstrate "reasonable care" to courts
• Reduce financial exposure when fraud occurs
• Satisfy insurance requirements
• Comply with duty of care obligations

Example: A bank implements dual authorization for wire transfers not because it prevents #9 social engineering (it doesn't—humans remain manipulable), but because:

1. Regulators mandate it
2. It reduces the bank's liability when fraud occurs
3. It demonstrates "reasonable security measures"
4. Courts expect it as industry standard

This is why banks "mix" these controls into cybersecurity programs even though they're fundamentally business/compliance controls.

Organizational Response: Case Class C

Primary responders:

• Human Resources (employee victims)
• Legal/Compliance/Police (fraud, extortion)
• Communications/PR (reputation attacks)
• Finance (financial fraud)

NOT primary responders:

• SOC/Security Operations (no system to investigate)
• Digital forensics (no compromised systems)
• CSIRT (no technical incident)

Case Class A & B: Cyber Incidents Anchored at #9

Definition

Social engineering that bridges into a technical attack chain. A System Risk Event occurs and one or more Data Risk Events follow. TLCTC+ further distinguishes:

• Class A — Core Cyber Incident: the classical TLCTC chain. The cause-side path plus DRE annotation captures everything. Example: #9 → #7 → #4 + [DRE: C]
• Class B — Hybrid Cyber-Enabled Harm: the same chain plus a nationally reportable Business Risk Event. Both + [DRE: ...] and + [BRE: ...] co-exist on the consequence side. Example: #9 → #4 + [DRE: C, I] + [BRE: Account Takeover Fraud]

Examples (with TLCTC+ notation)

• Phishing → Malware → Ransomware (Class A): #9 ||[email][@External→@Org]|| → #7 → #4 → (#1+#7) + [DRE: Ac]
• Credential harvesting → Access (Class A): #9 → #4 → #1 + [DRE: C] (Axiom X / R-CRED: acquisition is #9, application is #4)
• Account-takeover-enabled fraud (Class B): #9 ||[email][@External→@Citizen]|| →[Δt=hours] #4 + [DRE: C, I] + [BRE: Account Takeover Fraud]
• Fake tech-support with remote-access installation (Class B): #9 ||[human][@External→@Citizen]|| →[Δt=minutes] #7 + [DRE: C] + [BRE: Fake Tech Support Payment]
• Social engineering → Physical access (Class A): #9 → #8 → #7

The TLCTC Reality: Full Framework Applies

All cyber threat controls become relevant:

Technical Controls:

• Email filtering, URL reputation (detect malicious content)
• EDR, anti-malware (prevent code execution)
• MFA (prevent credential abuse)
• Network segmentation (limit lateral movement)
• Application whitelisting (control execution)
• SIEM/SOC (detect compromise)

PLUS Awareness Training:

• #9 is the initial vector, so awareness remains critical
• But awareness alone is insufficient—technical controls required

Velocity Matters (Δt)

In Class A & B sequences, attack velocity becomes measurable and critical:

#9 →[Δt=2h] #7 →[Δt=30m] #4 →[Δt=15m] (#1+#7) + [DRE: Ac]

Detection Coverage Score = (Mean Time to Detect) / (Attack Velocity)

Goal: DCS < 1.0 (detecting faster than attack progresses)

Organizational Response: Case Class A & B

Primary responders:

• SOC/Security Operations
• CSIRT/Incident Response
• Digital forensics
• IT operations

Supporting responders:

• HR (if employee accounts involved)
• Legal (breach notification, regulatory reporting)
• Communications (customer notification)

Why This Distinction Matters Operationally

Resource Allocation

Risk Assessment

Key insight: Same business outcome, different attack paths, different primary defenses, different risk levels.

Decision Framework: Quick Classification

Integration with Cyber Crime Frameworks

The TLCTC+ Class C vs. Class A/B distinction integrates cleanly with regulatory and legal frameworks:

Conclusion: Precision Through TLCTC+ Case Classes

Social Engineering (#9) remains a single cluster — but the cases that anchor on it span very different operational worlds. TLCTC+ resolves this on the consequence side, not the cause side, by adding a controlled + [BRE: ...] annotation alongside the existing + [DRE: ...]:

Class C (#9 + [BRE: ...]): Classical crime in a digital medium. No system is compromised. Cyber threat controls offer minimal value. Response is driven by liability exposure and regulatory compliance, not cyber threat management. Focus on awareness, law enforcement, and business process controls like transaction monitoring mandated by your legal/regulatory environment.

Class A (#9 → #N + [DRE: ...]): Cyber chain follows the social-engineering step. Full TLCTC framework applies. Technical defenses work because systems can be hardened (unlike human nature). Focus on prevention, detection, response, and measurable control effectiveness.

Class B (#9 → #N + [DRE: ...] + [BRE: ...]): Hybrid case. Both a cyber-incident DRE and a nationally reportable downstream harm exist. Both annotations co-exist on the consequence side; the SOC owns the cyber chain while NCSC/CERT/regulator-facing intake owns the BRE record.

The critical questions are: Did a System Risk Event occur? Did a DRE occur? Is there a nationally reportable BRE? Answer those three, and the case-class assignment — and the playbook — fall out automatically.

Keep TLCTC pure. Extend the reporting layer. The ten clusters stay unchanged; + [BRE: ...] reuses the existing additive Bow-Tie grammar already used by + [DRE: ...] — no new operator, no overload of the v2.1 transit operator ⇒.