567 lines
35 KiB
TypeScript
567 lines
35 KiB
TypeScript
export interface OnboardingExample {
|
|
text: string;
|
|
category?: string;
|
|
specificity?: string;
|
|
explanation: string;
|
|
}
|
|
|
|
export interface OnboardingStep {
|
|
id: number;
|
|
title: string;
|
|
subtitle: string;
|
|
content: string[];
|
|
examples?: OnboardingExample[];
|
|
keyPoints?: string[];
|
|
tip?: string;
|
|
}
|
|
|
|
export const ONBOARDING_STEPS: OnboardingStep[] = [
|
|
// ── Step 1: What You'll Be Doing ──────────────────────────────────────
|
|
{
|
|
id: 1,
|
|
title: "What You'll Be Doing",
|
|
subtitle: "A quick overview of the labeling task",
|
|
content: [
|
|
"You're going to read short paragraphs from SEC filings about cybersecurity and label them. No prior knowledge of SEC filings or cybersecurity is needed — we'll teach you everything right here.",
|
|
"Since 2023, the SEC requires every public company to disclose how they handle cybersecurity risk (in their annual 10-K filings, Item 1C) and any cybersecurity incidents (in 8-K filings). These disclosures are what you'll be reading.",
|
|
"Your job is simple: read each paragraph and answer two questions about it. That's it.",
|
|
"This tool is building a gold-standard dataset for training an AI classifier. There are 6 annotators total, with 3 annotators labeling each paragraph. You'll label roughly 600 paragraphs out of 1,200 total.",
|
|
],
|
|
keyPoints: [
|
|
"Each paragraph gets two labels: a Content Category and a Specificity Level.",
|
|
"You don't need any background in finance, law, or cybersecurity.",
|
|
"Your labels are the ground truth that an AI model will learn from — accuracy matters.",
|
|
],
|
|
},
|
|
|
|
// ── Step 2: The Two Questions ─────────────────────────────────────────
|
|
{
|
|
id: 2,
|
|
title: "The Two Questions",
|
|
subtitle: "Every paragraph gets exactly two labels",
|
|
content: [
|
|
'Question 1: "What is this paragraph about?" — this is the Content Category. You pick one of 7 options.',
|
|
'Question 2: "How specific is this paragraph?" — this is the Specificity Level. You pick one of 4 levels.',
|
|
"Every paragraph gets exactly one answer for each question. This is single-label classification — pick the BEST fit, not multiple labels.",
|
|
],
|
|
keyPoints: [
|
|
"Content Category: one of 7 mutually exclusive options.",
|
|
"Specificity Level: one of 4 levels from vague to very specific.",
|
|
"Always pick the single best answer for each dimension.",
|
|
],
|
|
},
|
|
|
|
// ── Step 3: Content Categories Overview ───────────────────────────────
|
|
{
|
|
id: 3,
|
|
title: "Content Categories Overview",
|
|
subtitle: "The 7 categories at a glance",
|
|
content: [
|
|
"There are 7 mutually exclusive content categories. Here's a plain-English way to think about each one:",
|
|
"Board Governance — Who's in charge at the board level?",
|
|
"Management Role — Who's the person running cybersecurity?",
|
|
"Risk Management Process — What does the company's cyber program actually do?",
|
|
"Third-Party Risk — How do they handle vendor/supplier risk?",
|
|
"Incident Disclosure — Did something bad actually happen?",
|
|
"Strategy Integration — What does cyber risk mean for the business/money?",
|
|
"None/Other — None of the above.",
|
|
"If a paragraph touches multiple categories, pick the dominant one — the category that takes up most of the paragraph's text.",
|
|
],
|
|
keyPoints: [
|
|
"7 categories, mutually exclusive — always pick exactly one.",
|
|
"When in doubt, pick the category that dominates the paragraph.",
|
|
],
|
|
},
|
|
|
|
// ── Step 4: Board Governance ──────────────────────────────────────────
|
|
{
|
|
id: 4,
|
|
title: "Board Governance",
|
|
subtitle: "Board or committee oversight of cybersecurity risk",
|
|
content: [
|
|
"Definition: Board or committee oversight of cybersecurity risk. The board or a board committee is the grammatical subject performing the primary action.",
|
|
'Look for language like: "Board of Directors oversees," "Audit Committee," "quarterly briefings," "board-level expertise."',
|
|
"IS Board Governance: Board receives reports, Audit Committee oversees cyber risk, directors review cybersecurity matters.",
|
|
"NOT Board Governance: CISO reports TO the board (that's Management Role — the CISO is the subject), board mentioned only in passing.",
|
|
],
|
|
examples: [
|
|
{
|
|
text: "The Board of Directors oversees the Company's management of cybersecurity risks.",
|
|
category: "Board Governance",
|
|
explanation:
|
|
"The board is the subject doing the overseeing. Classic Board Governance.",
|
|
},
|
|
{
|
|
text: "The Audit Committee receives quarterly reports from the CISO and conducts an annual deep-dive review of the Company's cybersecurity program, threat landscape, and incident response readiness.",
|
|
category: "Board Governance",
|
|
explanation:
|
|
"Even though the CISO is mentioned, the Audit Committee is the one performing the actions (receiving, conducting). The committee is the grammatical subject.",
|
|
},
|
|
{
|
|
text: "Our Board of Directors recognizes the critical importance of maintaining the trust and confidence of our customers and stakeholders, and cybersecurity risk is an area of increasing focus for our Board.",
|
|
category: "Board Governance",
|
|
explanation:
|
|
"Generic statement about board awareness — still Board Governance because the board is the subject performing the action (recognizing).",
|
|
},
|
|
],
|
|
tip: "The key test is always: who is the grammatical subject? If the board or a board committee is doing the action, it's Board Governance.",
|
|
},
|
|
|
|
// ── Step 5: Management Role ───────────────────────────────────────────
|
|
{
|
|
id: 5,
|
|
title: "Management Role",
|
|
subtitle: "Named officers or management teams responsible for cybersecurity",
|
|
content: [
|
|
"Definition: Named officers or management teams responsible for cybersecurity. A specific person or management function is the grammatical subject.",
|
|
"This category is about WHO THE PERSON IS — their background, credentials, experience, reporting structure.",
|
|
"IS Management Role: CISO's qualifications described, VP of Security's background, management committee structure.",
|
|
"NOT Management Role: CISO mentioned once and then the paragraph describes the program (that's Risk Management Process).",
|
|
],
|
|
examples: [
|
|
{
|
|
text: "Our Vice President of Information Security, who holds CISSP and CISM certifications and has over 20 years of experience in cybersecurity, reports directly to our Chief Information Officer.",
|
|
category: "Management Role",
|
|
explanation:
|
|
"It's about the person — their certifications, experience, and reporting line.",
|
|
},
|
|
{
|
|
text: "Our CISO, Sarah Chen, leads a dedicated cybersecurity team of 35 professionals. Ms. Chen joined the Company in 2019 after serving as Deputy CISO at a Fortune 100 financial services firm.",
|
|
category: "Management Role",
|
|
explanation:
|
|
"The paragraph tells you about Sarah Chen as a person — name, team, tenure, prior role.",
|
|
},
|
|
{
|
|
text: "Management is responsible for assessing and managing cybersecurity risks within the organization.",
|
|
category: "Management Role",
|
|
explanation:
|
|
"Generic, but still about who is responsible (management as the subject), not what the program does.",
|
|
},
|
|
],
|
|
tip: "Ask yourself: is this paragraph telling me about a person (or role), or about what the cybersecurity program does? If it's about the person, it's Management Role.",
|
|
},
|
|
|
|
// ── Step 6: Board vs Management — The Key Test ────────────────────────
|
|
{
|
|
id: 6,
|
|
title: "Board vs Management — The Key Test",
|
|
subtitle: "The #1 source of confusion between annotators",
|
|
content: [
|
|
"This is the single most common mistake. The test is simple: WHO is the grammatical subject performing the action?",
|
|
"Board or committee is the subject → Board Governance.",
|
|
"Named officer or management team is the subject → Management Role.",
|
|
'The Person-vs-Function test: If you removed the person\'s name, title, and credentials, does the paragraph still describe cybersecurity activities? If YES → it\'s about the function (Risk Management Process), not the person (Management Role). Naming a cybersecurity title like "CISO" or "CIO" does NOT automatically make it Management Role. The title is often just attribution before describing the program.',
|
|
],
|
|
examples: [
|
|
{
|
|
text: "The Board has delegated oversight of cybersecurity matters to the Audit Committee, which meets quarterly with the CISO.",
|
|
category: "Board Governance",
|
|
explanation:
|
|
"Board is the subject. The CISO is mentioned incidentally.",
|
|
},
|
|
{
|
|
text: "Our CISO reports quarterly to the Board on cybersecurity threats and program performance.",
|
|
category: "Management Role",
|
|
explanation:
|
|
"The CISO is the subject performing the action (reporting).",
|
|
},
|
|
{
|
|
text: "Our CISO oversees the Company's cybersecurity program, which includes risk assessments, vulnerability scanning, penetration testing, and incident response planning aligned with the NIST CSF framework.",
|
|
category: "Risk Management Process",
|
|
explanation:
|
|
'NOT Management Role! The CISO is mentioned once as attribution, but the paragraph is about what the program does. Remove "Our CISO oversees" and it still makes complete sense as a description of the program.',
|
|
},
|
|
],
|
|
keyPoints: [
|
|
"Who is the grammatical subject? Board → Board Governance. Officer → Management Role.",
|
|
"Person-vs-Function test: remove the name/title — does the paragraph still describe activities? If yes, it's Risk Management Process.",
|
|
"A CISO mention does NOT automatically mean Management Role.",
|
|
],
|
|
},
|
|
|
|
// ── Step 7: Risk Management Process ───────────────────────────────────
|
|
{
|
|
id: 7,
|
|
title: "Risk Management Process",
|
|
subtitle: "Internal cybersecurity program mechanics",
|
|
content: [
|
|
"Definition: Internal cybersecurity program mechanics — frameworks, assessments, controls, training, monitoring.",
|
|
'This is the "what do they actually do" category.',
|
|
"IS Risk Management Process: NIST framework adoption, penetration testing, employee training, SOC operations, vulnerability scanning.",
|
|
"NOT Risk Management Process: Vendor assessments (that's Third-Party Risk), incident response actions during a real incident (that's Incident Disclosure).",
|
|
],
|
|
examples: [
|
|
{
|
|
text: "We maintain a cybersecurity risk management program that is integrated into our overall enterprise risk management framework.",
|
|
category: "Risk Management Process",
|
|
explanation:
|
|
"Describing the program's existence and its integration into enterprise risk management.",
|
|
},
|
|
{
|
|
text: "Our cybersecurity program is aligned with the NIST Cybersecurity Framework and incorporates elements of ISO 27001. We conduct regular risk assessments and penetration testing.",
|
|
category: "Risk Management Process",
|
|
explanation:
|
|
"Framework adoption and specific program activities. All about the internal program.",
|
|
},
|
|
{
|
|
text: "We operate a 24/7 Security Operations Center that uses Splunk SIEM and CrowdStrike Falcon endpoint detection. Our incident response team conducts quarterly tabletop exercises simulating ransomware and supply chain compromise scenarios.",
|
|
category: "Risk Management Process",
|
|
explanation:
|
|
"Specific tools, team operations, and exercises. Very detailed, but still about the internal program — no real incident happened.",
|
|
},
|
|
],
|
|
tip: "If the paragraph describes what the cybersecurity program does day-to-day, it's almost always Risk Management Process.",
|
|
},
|
|
|
|
// ── Step 8: Third-Party Risk ──────────────────────────────────────────
|
|
{
|
|
id: 8,
|
|
title: "Third-Party Risk",
|
|
subtitle: "Oversight of external parties' cybersecurity",
|
|
content: [
|
|
"Definition: Oversight of external parties' cybersecurity — vendors, suppliers, service providers.",
|
|
"The key question: is the CENTRAL topic about overseeing someone outside the company?",
|
|
"IS Third-Party Risk: Vendor assessments, third-party audits, supply chain monitoring, SOC 2 requirements for vendors.",
|
|
"NOT Third-Party Risk: Internal program that happens to use third-party tools (Risk Management Process), hiring a firm to test YOUR systems (Risk Management Process).",
|
|
],
|
|
examples: [
|
|
{
|
|
text: "We face cybersecurity risks associated with our use of third-party service providers who may have access to our systems and data.",
|
|
category: "Third-Party Risk",
|
|
explanation: "About vendor risk exposure — the central topic is external parties.",
|
|
},
|
|
{
|
|
text: "Our vendor risk management program requires all third-party service providers with access to sensitive data to meet minimum security standards, including SOC 2 Type II certification.",
|
|
category: "Third-Party Risk",
|
|
explanation: "Requirements imposed on vendors. The focus is on what the company demands from external parties.",
|
|
},
|
|
{
|
|
text: "We assessed 312 vendors in fiscal 2024. All Tier 1 vendors are required to provide annual SOC 2 Type II reports. 14 vendors were placed on remediation plans and 3 vendor relationships were terminated.",
|
|
category: "Third-Party Risk",
|
|
explanation:
|
|
"Very specific vendor oversight with hard numbers. Still Third-Party Risk because the central topic is vendor management.",
|
|
},
|
|
],
|
|
tip: 'Watch out for the "hired a firm" trap. If a company says "we engaged Mandiant to conduct penetration testing," that\'s Risk Management Process — Mandiant is testing the company\'s own systems, not being overseen as a vendor.',
|
|
},
|
|
|
|
// ── Step 9: Incident Disclosure ───────────────────────────────────────
|
|
{
|
|
id: 9,
|
|
title: "Incident Disclosure",
|
|
subtitle: "Description of an actual cybersecurity incident",
|
|
content: [
|
|
"Definition: Description of an actual cybersecurity incident — what happened, the timeline, the impact, the response.",
|
|
"Key word: ACTUAL. Something really happened. Not hypothetical.",
|
|
'IS Incident Disclosure: "We detected unauthorized access," specific breach details, forensic investigation results.',
|
|
'NOT Incident Disclosure: Generic "we may experience incidents" (that\'s hypothetical risk language), incident response PLANS (that\'s Risk Management Process).',
|
|
],
|
|
examples: [
|
|
{
|
|
text: "On January 15, 2024, we detected unauthorized access to our customer support portal. The threat actor exploited a known vulnerability in a third-party software component.",
|
|
category: "Incident Disclosure",
|
|
explanation:
|
|
"A real event with a real date and real details. Something actually happened.",
|
|
},
|
|
{
|
|
text: "In December 2023, the Company experienced a cybersecurity incident involving unauthorized access to certain internal systems. The Company promptly took steps to contain and remediate the incident.",
|
|
category: "Incident Disclosure",
|
|
explanation:
|
|
"Real event, though vaguer than the previous example. Still describes something that actually occurred.",
|
|
},
|
|
{
|
|
text: "We have experienced, and may in the future experience, cybersecurity incidents that could have a material adverse effect on our business.",
|
|
category: "None/Other",
|
|
explanation:
|
|
"NOT Incident Disclosure. This is hypothetical risk language — no actual incident is described. Depending on context, this would be Strategy Integration or None/Other.",
|
|
},
|
|
],
|
|
keyPoints: [
|
|
"The incident must be REAL — something that actually happened.",
|
|
"Hypothetical risk language (\"we may experience\") is never Incident Disclosure.",
|
|
"Incident response plans and tabletop exercises are Risk Management Process, not Incident Disclosure.",
|
|
],
|
|
},
|
|
|
|
// ── Step 10: Strategy Integration ─────────────────────────────────────
|
|
{
|
|
id: 10,
|
|
title: "Strategy Integration",
|
|
subtitle: "Business and financial consequences of cyber risk",
|
|
content: [
|
|
"Definition: Business/financial consequences of cyber risk — budget, insurance, M&A impact, competitive impact, materiality assessments.",
|
|
'This is the "what does it mean for the business" category.',
|
|
'IMPORTANT RULE: Any paragraph that says cybersecurity risks have or could "materially affect" the business → Strategy Integration, even if it\'s boilerplate language.',
|
|
'IS Strategy Integration: Cyber budget amounts, insurance coverage, "not materially affected" statements, cost of incidents.',
|
|
"NOT Strategy Integration: Technical program costs mentioned in passing (that's Risk Management Process).",
|
|
],
|
|
examples: [
|
|
{
|
|
text: "We increased our cybersecurity budget by 32% to $45M in fiscal 2024. We maintain cyber liability insurance with $100M in aggregate coverage through AIG and Chubb.",
|
|
category: "Strategy Integration",
|
|
explanation:
|
|
"Dollar amounts and business decisions about cyber spending. This is about what cyber risk means for the business financially.",
|
|
},
|
|
{
|
|
text: "Cybersecurity risks have not materially affected, and are not reasonably likely to materially affect, our business strategy, results of operations, or financial condition.",
|
|
category: "Strategy Integration",
|
|
explanation:
|
|
"This is boilerplate that appears in thousands of filings, but it IS a materiality assessment — the company is making a strategic judgment about impact. Always Strategy Integration.",
|
|
},
|
|
{
|
|
text: "We have not identified any cybersecurity incidents that have materially affected us. For more information, see Item 1A, Risk Factors.",
|
|
category: "Strategy Integration",
|
|
explanation:
|
|
"The materiality assessment is the key content. The cross-reference at the end is just noise.",
|
|
},
|
|
],
|
|
tip: 'The "materially affect" rule is one of the most important. Whenever you see the word "materially" in the context of business impact, think Strategy Integration.',
|
|
},
|
|
|
|
// ── Step 11: None/Other ───────────────────────────────────────────────
|
|
{
|
|
id: 11,
|
|
title: "None/Other",
|
|
subtitle: "Doesn't fit any of the above categories",
|
|
content: [
|
|
"Definition: Doesn't fit any of the other 6 categories. Generic corporate language, section headers, cross-references, non-cyber content.",
|
|
"Specificity is always 1 (Generic Boilerplate) for None/Other paragraphs — there's no cyber content to rate.",
|
|
'SPAC rule: Companies that say "we have no operations" or "we have not adopted any cybersecurity program" → None/Other, even if they mention the board.',
|
|
'Cross-reference vs materiality: "See Item 1A, Risk Factors" alone = None/Other. But if it also includes "have not materially affected our business" = Strategy Integration.',
|
|
],
|
|
examples: [
|
|
{
|
|
text: "Item 1C. Cybersecurity",
|
|
category: "None/Other",
|
|
explanation: "Just a section header. No disclosure content.",
|
|
},
|
|
{
|
|
text: "For additional information about risks related to our information technology systems, see Part I, Item 1A, 'Risk Factors.'",
|
|
category: "None/Other",
|
|
explanation:
|
|
"Pure cross-reference with no disclosure content of its own.",
|
|
},
|
|
{
|
|
text: "We are a special purpose acquisition company with no business operations. We have not adopted any cybersecurity risk management program. Our Board of Directors is generally responsible for oversight of cybersecurity risks, if any.",
|
|
category: "None/Other",
|
|
explanation:
|
|
"Despite mentioning the Board, this company has no program — the board mention is perfunctory. SPACs with no operations get None/Other.",
|
|
},
|
|
],
|
|
keyPoints: [
|
|
"None/Other always gets Specificity 1.",
|
|
"SPACs with no operations → None/Other, even if they mention the board.",
|
|
"Pure cross-references → None/Other. Cross-references with materiality language → Strategy Integration.",
|
|
],
|
|
},
|
|
|
|
// ── Step 12: Decision Rules Recap ─────────────────────────────────────
|
|
{
|
|
id: 12,
|
|
title: "Decision Rules Recap",
|
|
subtitle: "Quick-reference rules for tricky cases",
|
|
content: [
|
|
"Here are the 6 decision rules that handle the most common edge cases:",
|
|
"Rule 1 — Dominant Category: If a paragraph spans multiple categories, assign the one that takes up the most text.",
|
|
"Rule 2 — Board vs Management: Who is the grammatical subject? Board/committee → Board Governance. Named officer/team → Management Role.",
|
|
"Rule 2b — Person vs Function: Is the paragraph about the person or what the program does? Remove the name/title — if the paragraph still describes activities, it's Risk Management Process.",
|
|
"Rule 3 — Risk Management vs Third-Party: Is the central topic internal processes or vendor oversight?",
|
|
"Rule 4 — Incident vs Strategy: What happened (Incident Disclosure) vs what it means for the business (Strategy Integration).",
|
|
"Rule 5 — None/Other Threshold: Only assign None/Other when there's no substantive cyber disclosure.",
|
|
"Rule 6 — Materiality Disclaimers: Any paragraph with a materiality assessment always goes to Strategy Integration.",
|
|
],
|
|
keyPoints: [
|
|
"Rule 1: Dominant category wins when a paragraph spans multiple topics.",
|
|
"Rule 2: Grammatical subject determines Board Governance vs Management Role.",
|
|
"Rule 2b: Person-vs-Function test — remove the name and see if the paragraph still works.",
|
|
"Rule 3: Internal processes → Risk Management Process. Vendor oversight → Third-Party Risk.",
|
|
"Rule 4: Real event → Incident Disclosure. Business impact → Strategy Integration.",
|
|
"Rule 5: None/Other only when there's no substantive disclosure.",
|
|
"Rule 6: Materiality disclaimers → always Strategy Integration.",
|
|
],
|
|
},
|
|
|
|
// ── Step 13: Specificity — What It Measures ───────────────────────────
|
|
{
|
|
id: 13,
|
|
title: "Specificity — What It Measures",
|
|
subtitle: "The second dimension: how company-specific is the disclosure?",
|
|
content: [
|
|
"Now for the second question you'll answer for every paragraph: Specificity Level.",
|
|
'Think of it this way: "Could you paste this paragraph into any company\'s filing and it would still make sense?"',
|
|
"If yes → low specificity (it's generic boilerplate).",
|
|
"If no, because it mentions this specific company's people, tools, numbers, or dates → high specificity.",
|
|
"There are 4 levels, from vague to very specific:",
|
|
"Level 1 — Generic Boilerplate: Could appear in any filing unchanged.",
|
|
"Level 2 — Sector-Adapted: Names a recognized standard but nothing unique to this company.",
|
|
"Level 3 — Firm-Specific: Contains at least one fact unique to this company.",
|
|
"Level 4 — Quantified-Verifiable: Contains two or more hard verifiable facts.",
|
|
"None/Other paragraphs always get Specificity 1.",
|
|
],
|
|
keyPoints: [
|
|
"Specificity measures how unique the disclosure is to this specific company.",
|
|
"4 levels: Generic Boilerplate (1) → Sector-Adapted (2) → Firm-Specific (3) → Quantified-Verifiable (4).",
|
|
"None/Other paragraphs are always Specificity 1.",
|
|
],
|
|
},
|
|
|
|
// ── Step 14: Generic Boilerplate & Sector-Adapted (Levels 1-2) ───────
|
|
{
|
|
id: 14,
|
|
title: "Generic Boilerplate & Sector-Adapted (Levels 1-2)",
|
|
subtitle: "The lower specificity levels",
|
|
content: [
|
|
"Level 1 — Generic Boilerplate: Could appear in any company's filing unchanged. No named frameworks, tools, people, dates, or quantities.",
|
|
"Level 2 — Sector-Adapted: Names a recognized standard (NIST, ISO 27001, SOC 2, PCI DSS, HIPAA, etc.) but nothing unique to THIS company.",
|
|
"The jump from Level 1 to Level 2: does the paragraph name a specific standard or framework? If yes, and there are no other company-specific facts, it's Level 2.",
|
|
],
|
|
examples: [
|
|
{
|
|
text: "We maintain a cybersecurity risk management program designed to identify, assess, and manage material cybersecurity risks.",
|
|
specificity: "Level 1 — Generic Boilerplate",
|
|
explanation:
|
|
"Could be any company. No named frameworks, tools, people, or details of any kind.",
|
|
},
|
|
{
|
|
text: "Management is responsible for assessing and managing cybersecurity risks within the organization.",
|
|
specificity: "Level 1 — Generic Boilerplate",
|
|
explanation:
|
|
"No named roles, frameworks, or details. Completely interchangeable between companies.",
|
|
},
|
|
{
|
|
text: "Our cybersecurity program is aligned with the NIST Cybersecurity Framework and incorporates elements of ISO 27001.",
|
|
specificity: "Level 2 — Sector-Adapted",
|
|
explanation:
|
|
"Names NIST and ISO 27001, but nothing unique to this company — many companies say the exact same thing.",
|
|
},
|
|
{
|
|
text: "We conduct regular risk assessments, vulnerability scanning, and penetration testing as part of our continuous monitoring approach.",
|
|
specificity: "Level 1 — Generic Boilerplate",
|
|
explanation:
|
|
"NOT Sector-Adapted. These are common practices, but they don't name a specific standard. Activities alone don't bump you to Level 2.",
|
|
},
|
|
],
|
|
tip: "Common practices like penetration testing and vulnerability scanning do NOT trigger Level 2. You need a named standard or framework (NIST, ISO, SOC 2, etc.) to reach Level 2.",
|
|
},
|
|
|
|
// ── Step 15: Firm-Specific & Quantified-Verifiable (Levels 3-4) ──────
|
|
{
|
|
id: 15,
|
|
title: "Firm-Specific & Quantified-Verifiable (Levels 3-4)",
|
|
subtitle: "The higher specificity levels",
|
|
content: [
|
|
"Level 3 — Firm-Specific: Contains at least one fact unique to THIS company.",
|
|
"Level 4 — Quantified-Verifiable: Contains TWO or more hard verifiable facts.",
|
|
"What counts as a specific fact (triggers Level 3): cybersecurity-specific titles (CISO, CTO, CIO, VP of Security), named non-generic committees (Technology Committee, Cybersecurity Committee — NOT Audit Committee since every company has one), specific dates, named tools (Splunk, CrowdStrike, Azure Sentinel), named third-party firms (Mandiant, Deloitte), specific numbers (headcounts, dollar amounts, percentages).",
|
|
"What does NOT count as a specific fact: generic governance terms (the Board, Audit Committee, management), generic C-suite titles (CEO, CFO, COO — not cybersecurity-specific), unnamed entities (third-party experts, external consultants), generic cadences (quarterly, annual without exact dates), common practices (penetration testing, vulnerability scanning).",
|
|
],
|
|
examples: [
|
|
{
|
|
text: "Our CISO oversees a team of 12 security professionals.",
|
|
specificity: "Level 3 — Firm-Specific",
|
|
explanation:
|
|
"CISO (cybersecurity-specific title) is one specific fact. But just one fact, so Level 3, not Level 4.",
|
|
},
|
|
{
|
|
text: "Our CISO, Sarah Chen, holds CISSP and CISM certifications and has over 20 years of experience. She joined the Company in 2019 after serving as Deputy CISO at a Fortune 100 firm.",
|
|
specificity: "Level 4 — Quantified-Verifiable",
|
|
explanation:
|
|
"Named person + named certifications + years of experience + specific year = 4+ verifiable facts. Easily clears the 2-fact threshold for Level 4.",
|
|
},
|
|
{
|
|
text: "The Audit Committee oversees cybersecurity risk.",
|
|
specificity: "Level 1 — Generic Boilerplate",
|
|
explanation:
|
|
"\"Audit Committee\" is NOT a specific fact — every public company has one. No other specifics present.",
|
|
},
|
|
],
|
|
keyPoints: [
|
|
"Cybersecurity-specific titles (CISO, CIO, CTO) count as specific facts. Generic titles (CEO, CFO) do not.",
|
|
"Audit Committee is NOT a specific fact — it's generic governance.",
|
|
"Level 4 requires two or more HARD verifiable facts: dates, dollars, headcounts, named firms, named tools, named certifications, years of experience.",
|
|
"Named roles and committees trigger Level 3 but do NOT count toward the Level 4 threshold.",
|
|
],
|
|
},
|
|
|
|
// ── Step 16: The Specificity Decision Test ────────────────────────────
|
|
{
|
|
id: 16,
|
|
title: "The Specificity Decision Test",
|
|
subtitle: "A step-by-step waterfall to determine specificity",
|
|
content: [
|
|
"Apply this waterfall — stop at the first yes:",
|
|
"Step A: Count ONLY hard verifiable facts: specific dates (month+year or exact date), dollar amounts, headcounts, percentages, named third-party firms, named products/tools, named certifications held by individuals, years of experience as a specific number. Two or more? → Level 4 (Quantified-Verifiable).",
|
|
"Step B: At least one fact from the specific-facts list (cybersecurity titles, named committees, named tools, named firms, specific dates, specific numbers)? → Level 3 (Firm-Specific).",
|
|
"Step C: Names a recognized standard (NIST, ISO, SOC 2, PCI DSS, HIPAA, etc.)? → Level 2 (Sector-Adapted).",
|
|
"Step D: None of the above? → Level 1 (Generic Boilerplate).",
|
|
"Important: named roles (CISO, CIO) and named committees trigger Firm-Specific (Level 3) but do NOT count toward the 2-fact threshold for Quantified-Verifiable (Level 4). Named frameworks (NIST, ISO) also do not count toward Level 4.",
|
|
],
|
|
examples: [
|
|
{
|
|
text: "We operate a 24/7 Security Operations Center that uses Splunk SIEM and CrowdStrike Falcon endpoint detection. Our incident response team conducts quarterly tabletop exercises.",
|
|
specificity: "Level 4 — Quantified-Verifiable",
|
|
explanation:
|
|
"Count QV facts: Splunk (named tool) + CrowdStrike Falcon (named tool) = 2 hard verifiable facts. Meets the threshold → Level 4.",
|
|
},
|
|
{
|
|
text: "Our CISO oversees the cybersecurity program aligned with NIST CSF.",
|
|
specificity: "Level 3 — Firm-Specific",
|
|
explanation:
|
|
"Count QV facts: none (CISO is a role, NIST is a framework — neither counts toward QV). Specific-facts list: CISO (yes, cybersecurity-specific title). → Level 3.",
|
|
},
|
|
{
|
|
text: "Our cybersecurity program incorporates elements of ISO 27001.",
|
|
specificity: "Level 2 — Sector-Adapted",
|
|
explanation:
|
|
"Count QV facts: none. Specific-facts list: none (ISO is a standard, not a firm-specific fact). Named standard: ISO 27001 (yes). → Level 2.",
|
|
},
|
|
],
|
|
tip: "When in doubt, count the verifiable facts on your fingers. If you can point to two things that an outside observer could independently confirm, it's Level 4.",
|
|
},
|
|
|
|
// ── Step 17: Putting It All Together ──────────────────────────────────
|
|
{
|
|
id: 17,
|
|
title: "Putting It All Together",
|
|
subtitle: "Borderline cases that exercise both dimensions",
|
|
content: [
|
|
"Let's work through some tricky examples that require you to assign BOTH a content category and a specificity level. These are the kinds of paragraphs that trip people up.",
|
|
],
|
|
examples: [
|
|
{
|
|
text: "The Audit Committee, which includes two members with significant technology expertise, receives quarterly reports from the CISO and conducts an annual deep-dive review of the cybersecurity program.",
|
|
category: "Board Governance",
|
|
specificity: "Level 3 — Firm-Specific",
|
|
explanation:
|
|
"Board Governance because the Audit Committee is the grammatical subject doing the actions (receiving reports, conducting reviews). Specificity: CISO is a cybersecurity-specific title — that's one specific fact, so Level 3. The Audit Committee itself doesn't count as a specific fact (every company has one).",
|
|
},
|
|
{
|
|
text: "Our CISO oversees the Company's cybersecurity program, which includes risk assessments, vulnerability scanning, penetration testing, and incident response planning aligned with the NIST CSF framework.",
|
|
category: "Risk Management Process",
|
|
specificity: "Level 3 — Firm-Specific",
|
|
explanation:
|
|
"Risk Management Process, NOT Management Role — the paragraph is about what the program does, and the CISO is just attribution. Apply the Person-vs-Function test: remove \"Our CISO oversees\" and the paragraph still describes the program perfectly. For specificity, the CISO mention still counts as a firm-specific fact even when it's just attribution, so Level 3.",
|
|
},
|
|
{
|
|
text: "Cybersecurity risks have not materially affected our business strategy, results of operations, or financial condition. For more information, see Item 1A, Risk Factors.",
|
|
category: "Strategy Integration",
|
|
specificity: "Level 1 — Generic Boilerplate",
|
|
explanation:
|
|
"Strategy Integration because the materiality assessment is the key content — the cross-reference is just noise. Generic Boilerplate because there are no specific facts, no named frameworks — this is pure boilerplate language that appears in thousands of filings.",
|
|
},
|
|
{
|
|
text: "We are a blank check company formed for the purpose of effecting a merger. We have not adopted any cybersecurity risk management program or formal processes for assessing cybersecurity risk.",
|
|
category: "None/Other",
|
|
specificity: "Level 1 — Generic Boilerplate",
|
|
explanation:
|
|
"None/Other because there's no substantive disclosure — this is a SPAC with no cybersecurity program. Specificity is always Level 1 for None/Other.",
|
|
},
|
|
],
|
|
keyPoints: [
|
|
"Always assign both a content category AND a specificity level.",
|
|
"The Person-vs-Function test and the Specificity Decision Test work together — use both.",
|
|
"You're ready for the quiz! You'll answer 8 questions testing these concepts. You need 7/8 to pass.",
|
|
],
|
|
},
|
|
];
|