{/* Table of Contents */} {/* ================================================================ SECTION 1: OVERVIEW ================================================================ */}

1. Overview

Unit of analysis: One paragraph from an SEC filing (Item 1C of 10-K, or Item 1.05/8.01/7.01 of 8-K).

Classification type: Multi-class (single-label), NOT multi-label. Each paragraph receives exactly one content category.

Each paragraph receives two labels:

Content Category — single-label, one of 7 mutually exclusive classes
Specificity Level — ordinal integer 1–4

None/Other policy: Required. Since this is multi-class (not multi-label), we need a catch-all for paragraphs that don’t fit the 6 substantive categories. A paragraph receives None/Other when it contains no cybersecurity-specific disclosure content (e.g., forward-looking statement disclaimers, section headers, general business language).

{/* ================================================================ SECTION 2: CONTENT CATEGORIES ================================================================ */}

2. Content Categories

Each paragraph is assigned exactly one content category. If a paragraph spans multiple categories, assign the{" "} dominant category — the one that best describes the paragraph’s primary communicative purpose.

{/* ---------- Board Governance ---------- */}

Board Governance

SEC basis: Item 106(c)(1)
Covers: Board or committee oversight of cybersecurity risks, briefing frequency, board member cybersecurity expertise
Key markers: “Audit Committee,” “Board of Directors oversees,” “quarterly briefings,” “board-level expertise,” “board committee”
Assign when: The grammatical subject performing the primary action is the board or a board committee

{/* ---------- Management Role ---------- */}

Management Role

SEC basis: Item 106(c)(2)
Covers: The specific person filling a cybersecurity leadership position: their name, qualifications, career history, credentials, tenure, reporting lines, management committees responsible for cybersecurity
Key markers: “Chief Information Security Officer,” “reports to,” “years of experience,” “management committee,” “CISSP,” “CISM,” named individuals, career background
Assign when: The paragraph tells you something about who the person is — their background, credentials, experience, or reporting structure. A paragraph that names a CISO/CIO/CTO and then describes what the cybersecurity{" "} program does is NOT Management Role — it is Risk Management Process with an incidental role attribution. The test is whether the paragraph is about the person or about the function.

The person-vs-function test:

If you removed the role holder’s name, title, qualifications, and background from the paragraph and the remaining content still describes substantive cybersecurity activities, processes, or oversight → the paragraph is about the function (Risk Management Process), not the person (Management Role). Management Role requires the person’s identity or credentials to be the primary content, not just a brief attribution of who runs the program.

{/* ---------- Risk Management Process ---------- */}

Risk Management Process

SEC basis: Item 106(b)
Covers: Risk assessment methodology, framework adoption (NIST, ISO, etc.), vulnerability management, monitoring, incident response planning, tabletop exercises, ERM integration
Key markers: “NIST CSF,” “ISO 27001,” “risk assessment,” “vulnerability management,” “tabletop exercises,” “incident response plan,” “SOC,” “SIEM”
Assign when: The paragraph primarily describes the company’s internal cybersecurity processes, tools, or methodologies

{/* ---------- Third-Party Risk ---------- */}

Third-Party Risk

SEC basis: Item 106(b)
Covers: Vendor/supplier risk oversight, external assessor engagement, contractual security requirements, supply chain risk management
Key markers: “third-party,” “service providers,” “vendor risk,” “external auditors,” “supply chain,” “SOC 2 report,” “contractual requirements”
Assign when: The central topic is oversight of external parties’ cybersecurity, not the company’s own internal processes

{/* ---------- Incident Disclosure ---------- */}

Incident Disclosure

SEC basis: 8-K Item 1.05 (and 8.01/7.01 post-May 2024)
Covers: Description of cybersecurity incidents — nature, scope, timing, impact assessment, remediation actions, ongoing investigation
Key markers: “unauthorized access,” “detected,” “incident,” “remediation,” “impacted,” “forensic investigation,” “breach,” “compromised”
Assign when: The paragraph primarily describes what happened in a cybersecurity incident

{/* ---------- Strategy Integration ---------- */}

Strategy Integration

SEC basis: Item 106(b)(2)
Covers: Material impact (or lack thereof) on business strategy or financials, cybersecurity insurance, investment/resource allocation, cost of incidents
Key markers: “business strategy,” “insurance,” “investment,” “material,” “financial condition,” “budget,” “not materially affected,” “results of operations”
Assign when: The paragraph primarily discusses business/financial consequences or strategic response to cyber risk, not the risk management activities themselves
Includes materiality disclaimers: Any paragraph that explicitly assesses whether cybersecurity risks have or could “materially affect” the company’s business, strategy, financial condition, or results of operations is Strategy Integration — even if the assessment is boilerplate. The company is making a strategic judgment about cyber risk impact, which is the essence of this category. A cross-reference to Risk Factors appended to a materiality assessment does not change the classification.

{/* ---------- None/Other ---------- */}

None/Other

Covers: Forward-looking statement disclaimers, section headers, cross-references to other filing sections, general business language that mentions cybersecurity incidentally, text erroneously extracted from outside Item 1C/1.05
No specificity scoring needed: Always assign Specificity 1 for None/Other paragraphs (since there is no cybersecurity disclosure to rate)
SPACs and shell companies: Companies that explicitly state they have no operations, no cybersecurity program, or no formal processes receive None/Other regardless of incidental mentions of board oversight or risk acknowledgment. The absence of a program is not a description of a program. Paragraphs like “We have not adopted any cybersecurity risk management program. Our board is generally responsible for oversight” are None/Other — the board mention is perfunctory, not substantive governance disclosure.
Distinguishing from Strategy Integration: A pure cross-reference (“See Item 1A, Risk Factors”) with no materiality assessment is None/Other. But if the paragraph includes an explicit materiality conclusion (“have not materially affected our business strategy”), it becomes Strategy Integration even if a cross-reference is also present. The test: does the paragraph make a substantive claim about cybersecurity’s impact on the business? If yes → Strategy Integration. If it only points elsewhere → None/Other.

{/* ================================================================ SECTION 3: CATEGORY DECISION RULES ================================================================ */}

3. Category Decision Rules {/* Rule 1 */}

Rule 1: Dominant Category

If a paragraph spans multiple categories, assign the one whose topic occupies the most text or is the paragraph’s primary communicative purpose.

{/* Rule 2 */}

Rule 2: Board vs. Management Signal Category Board/committee is the grammatical subject Board Governance Board delegates responsibility to management Board Governance Management role reports TO the board Management Role Management role’s qualifications are described Management Role “Board oversees... CISO reports to Board quarterly” Board Governance (board is primary actor) “CISO reports quarterly to the Board on...” Management Role (CISO is primary actor)

{/* Rule 2b */}

Rule 2b: Person-vs-Function Test (Management Role vs. Risk Management Process)

This is the single most common source of annotator disagreement. The line is: is the paragraph about the person or about the function?

Signal Category The person’s background, credentials, tenure, experience, education, career history Management Role The person’s name is given Management Role (strong signal) Reporting lines as primary content (who reports to whom, management committee structure) Management Role Role title mentioned as attribution (“Our CISO oversees...”) followed by process description Risk Management Process Activities, tools, methodologies, frameworks as the primary content Risk Management Process The paragraph would still make sense if you removed the role title and replaced it with “the Company” Risk Management Process

Key principle:

Naming a cybersecurity leadership title (CISO, CIO, CTO, VP of Security) does not make a paragraph Management Role. The title is often an incidental attribution — the paragraph names who is responsible then describes what the program does. If the paragraph’s substantive content is about processes, activities, or tools, it is Risk Management Process regardless of how many times a role title appears. Management Role requires the paragraph’s content to be about the person — who they are, what makes them qualified, how long they’ve served, what their background is.

{/* Rule 3 */}

Rule 3: Risk Management vs. Third-Party Signal Category Company’s own internal processes, tools, teams Risk Management Process Third parties mentioned as ONE component of internal program Risk Management Process Vendor oversight is the CENTRAL topic Third-Party Risk External assessor hired to test the company Risk Management Process (they serve the company) Requirements imposed ON vendors Third-Party Risk

{/* Rule 4 */}

Rule 4: Incident vs. Strategy Signal Category Describes what happened (timeline, scope, response) Incident Disclosure Describes business impact of an incident (costs, revenue, insurance claim) Strategy Integration Mixed: “We detected X... at a cost of $Y” Assign based on which is dominant — if cost is one sentence in a paragraph about the incident → Incident Disclosure

{/* Rule 5 */}

Rule 5: None/Other Threshold

Assign None/Other ONLY when the paragraph contains no substantive cybersecurity disclosure content. If a paragraph mentions cybersecurity even briefly in service of a disclosure obligation, assign the relevant content category.

Exception — SPACs and no-operations companies:

A paragraph that explicitly states the company has no cybersecurity program, no operations, or no formal processes is None/Other even if it perfunctorily mentions board oversight or risk acknowledgment. The absence of a program is not substantive disclosure.

{/* Rule 6 */}

Rule 6: Materiality Disclaimers → Strategy Integration

Any paragraph that explicitly assesses whether cybersecurity risks or incidents have “materially affected” (or are “reasonably likely to materially affect”) the company’s business strategy, results of operations, or financial condition is Strategy Integration — even when the assessment is boilerplate. The materiality assessment is the substantive content. A cross-reference to Risk Factors appended to a materiality assessment does not change the classification to None/Other. Only a pure cross-reference with no materiality conclusion is None/Other.

{/* ================================================================ SECTION 4: SPECIFICITY LEVELS ================================================================ */}

4. Specificity Levels

Each paragraph receives a specificity level (1–4) indicating how company-specific the disclosure is. Apply the decision test in order — stop at the first “yes.”

{/* Decision Test */}

Decision Test (Waterfall)

Count hard verifiable facts ONLY (specific dates, dollar amounts, headcounts/percentages, named third-party firms, named products/tools, named certifications). At least ONE? → Quantified-Verifiable (4)
Does it contain at least one fact from the IS list below? → Firm-Specific (3)
Does it use any cybersecurity domain terminology?{" "} (penetration testing, vulnerability scanning, SIEM, SOC, EDR, NIST CSF, ISO 27001, zero trust, etc.) →{" "} Domain-Adapted (2)
None of the above? →{" "} Generic Boilerplate (1)

None/Other paragraphs always receive Specificity 1.

{/* Level Definitions */}

Level Definitions Level Name Description 1 Generic Boilerplate Could paste into any company’s filing unchanged. No named entities, frameworks, roles, dates, or specific details. 2 Domain-Adapted Uses cybersecurity domain terminology (penetration testing, vulnerability scanning, SIEM, SOC, EDR, NIST CSF, ISO 27001, zero trust, etc.) but contains nothing unique to THIS company. 3 Firm-Specific Contains at least one fact from the IS list that identifies something unique to THIS company’s disclosure. 4 Quantified-Verifiable Contains at least one hard verifiable fact that an external party could independently verify (see QV-eligible list).

{/* IS list */}

IS a Specific Fact (any ONE → at least Firm-Specific)

Cybersecurity-specific titles: CISO, CTO, CIO, VP of IT/Security, Information Security Officer, Director of IT Security, Cybersecurity Director, Chief Digital Officer (when overseeing cyber)

Named non-generic committees: Technology Committee, Cybersecurity Committee, Cybersecurity Steering Committee, Risk Committee (NOT “Audit Committee” — that exists at every public company)

Specific team/department compositions: “Legal, Compliance, and Finance” (but NOT just “a cross-functional team”)

Named internal programs with unique identifiers: “Cyber Incident Response Plan (CIRP)” (must have a distinguishing name/abbreviation — generic “incident response plan” does not qualify)

Named individuals in a cybersecurity role context

Specific organizational claims: “24/7 security operations” (implies specific organizational investment beyond generic monitoring)

{/* IS NOT list */}

IS NOT a Specific Fact (do NOT use to justify Firm-Specific)

Generic governance: “the Board”, “Board of Directors”, “management”, “Audit Committee”, “the Committee”

Generic C-suite: CEO, CFO, COO, President, General Counsel — these exist at every company and are not cybersecurity-specific

Generic IT leadership (NOT cybersecurity-specific): “Head of IT”, “IT Manager”, “Director of IT”, “Chief Compliance Officer”, “Associate Vice President of IT” — these are general corporate/IT titles, not cybersecurity roles per the IS list

Unnamed entities: “third-party experts”, “external consultants”, “cybersecurity firms”, “managed service provider”

Generic cadences: “quarterly”, “annual”, “periodic”, “regular” — without exact dates

Boilerplate phrases: “cybersecurity risks”, “material adverse effect”, “business operations”, “financial condition”

Standard incident language: “forensic investigation”, “law enforcement”, “regulatory obligations”, “incident response protocols”

Vague quantifiers: “certain systems”, “some employees”, “a number of”, “a portion of”

Generic ERM terms: “risk assessment”, “incident response plan”, “business continuity”, “tabletop exercises” (without cybersecurity qualifier), “internal controls”, “compliance”

Generic program names: “incident response plan”, “business continuity plan”, “cybersecurity program”, “Third-Party Risk Management Program”, “Company-wide training” — no unique identifier or distinguishing abbreviation

Company self-references: the company’s own name, “the Company”, “the Bank”, subsidiary names, filing form types

Company milestones: “since our IPO”, “since inception” — not cybersecurity facts

{/* QV-Eligible Facts */}

QV-Eligible Facts (any one triggers Quantified-Verifiable)

Specific dates (month+year or exact date)
Dollar amounts, headcounts, percentages
Named third-party firms (Mandiant, CrowdStrike, Deloitte)
Named products/tools (Splunk, Azure Sentinel)
Named certifications held by individuals (CISSP, CISM, CEH)
Years of experience as a specific number (“17 years”, “over 20 years”)
Named universities in credential context

{/* Do NOT count toward QV */}

NOT QV-Eligible (these trigger Firm-Specific or Domain-Adapted, not QV)

Named roles (CISO, CIO)
Named committees
Named frameworks followed (NIST, ISO 27001) — these trigger Domain-Adapted
Team compositions, reporting structures
Named internal programs
Generic degrees without named university (“BS in Management”)

{/* Validation Step */}

Validation Step

Before finalizing specificity, review the extracted facts. Remove any that appear on the NOT list. If no facts remain after filtering → Generic Boilerplate (or Domain-Adapted if domain terminology is present). Do not let NOT-list items inflate the specificity rating.

{/* ================================================================ SECTION 5: BORDERLINE CASES ================================================================ */}

5. Borderline Cases {/* Case 1 */}

Case 1: Framework mention + firm-specific fact

“We follow NIST CSF and our CISO oversees the program.”

The NIST mention → Level 2 anchor. The CISO reference → firm-specific. Apply boundary rule 2→3:{" "} “Does it mention anything unique to THIS company?” Yes (CISO role exists at this company) →{" "} Level 3.

{/* Case 2 */}

Case 2: Named role but generic description

“Our Chief Information Security Officer is responsible for managing cybersecurity risks.”

Names a role (CISO) → potentially Level 3. But the description is completely generic. Apply judgment: the mere existence of a CISO title is firm-specific (not all companies have one). → Level 3. If the paragraph said “a senior executive is responsible” without naming the role → Level 1.

{/* Case 3 */}

Case 3: Specificity-rich None/Other

“On March 15, 2025, we filed a Current Report on Form 8-K disclosing a cybersecurity incident. For details, see our Form 8-K filed March 15, 2025, accession number 0001193125-25-012345.”

Contains specific dates and filing numbers, but the paragraph itself contains no disclosure content — it’s a cross-reference. → None/Other, Specificity 1.{" "} Specificity only applies to disclosure substance, not to metadata.

{/* Case 4 */}

Case 4: Hypothetical incident language in 10-K

“We may experience cybersecurity incidents that could disrupt our operations.”

This appears in Item 1C, not an 8-K. It describes no actual incident. →{" "} Risk Management Process or Strategy Integration (depending on context), NOT Incident Disclosure. {" "} Incident Disclosure is reserved for descriptions of events that actually occurred.

{/* Case 5 */}

Case 5: Dual-category paragraph

“The Audit Committee oversees our cybersecurity program, which is led by our CISO who holds CISSP certification and reports quarterly to the Committee.”

Board (Audit Committee oversees) + Management (CISO qualifications, reporting). The opening clause sets the frame: this is about the Audit Committee’s oversight, and the CISO detail is subordinate. → Board Governance, Specificity 4{" "} (CISSP is a QV-eligible certification — verifiable via ISC2).

{/* Case 6 */}

Case 6: Management Role vs. Risk Management Process — the person-vs-function test

“Our CISO oversees the Company’s cybersecurity program, which includes risk assessments, vulnerability scanning, and incident response planning. The program is aligned with the NIST CSF framework and integrated into our enterprise risk management process.”

The CISO is named as attribution, but the paragraph is about what the program does — assessments, scanning, response planning, framework alignment, ERM integration. Remove “Our CISO oversees” and it still makes complete sense as a process description. →{" "} Risk Management Process, Specificity 2 (NIST CSF framework, no firm-specific facts beyond that).

“Our CISO has over 20 years of experience in cybersecurity and holds CISSP and CISM certifications. She reports directly to the CIO and oversees a team of 12 security professionals. Prior to joining the Company in 2019, she served as VP of Security at a Fortune 500 technology firm.”

The entire paragraph is about the person: experience, certifications, reporting line, team size, tenure, prior role. → Management Role, Specificity 4 (years of experience + team headcount + named certifications = multiple QV-eligible facts).

{/* Case 7 */}

Case 7: Materiality disclaimer — Strategy Integration vs. None/Other

“We have not identified any cybersecurity incidents or threats that have materially affected our business strategy, results of operations, or financial condition. However, like other companies, we have experienced threats from time to time. For more information, see Item 1A, Risk Factors.”

Contains an explicit materiality assessment (“materially affected... business strategy, results of operations, or financial condition”). The cross-reference and generic threat mention are noise. →{" "} Strategy Integration, Specificity 1.

“For additional information about risks related to our information technology systems, see Part I, Item 1A, ‘Risk Factors.’”

No materiality assessment. Pure cross-reference. →{" "} None/Other, Specificity 1.

{/* Case 8 */}

Case 8: SPAC / no-operations company

“We are a special purpose acquisition company with no business operations. We have not adopted any cybersecurity risk management program or formal processes. Our Board of Directors is generally responsible for oversight of cybersecurity risks, if any. We have not encountered any cybersecurity incidents since our IPO.”

Despite touching RMP (no program), Board Governance (board is responsible), and Strategy Integration (no incidents), the paragraph contains no substantive disclosure. The company explicitly has no program, and the board mention is perfunctory (“generally responsible... if any”). The absence of a program is not a program description. →{" "} None/Other, Specificity 1.

{/* Bottom spacer */}