SEC-Enforcement Cybersecurity Risk Management and Incident Disclosure

To operationalize the sec-enforcement cybersecurity risk management and incident disclosure requirement, treat it as an anti-misleading-statements control: your cybersecurity program and incident communications must match what you tell clients, prospects, and regulators. Build written governance, risk assessment, protective controls, and an incident triage-and-disclosure decision log that proves your statements were accurate and your decisions were documented.

Key takeaways:

• Map every public cybersecurity claim (marketing, RFPs, DDQs, website) to real controls, owners, and review cadence to avoid “false or misleading” statements. (17 CFR 275.206(4)-1)
• Run a formal incident materiality and disclosure workflow with documented approvals, timestamps, and evidence retained.
• Use periodic control validation (tabletops, targeted tests) to confirm the program still matches disclosed practices, and track remediation to closure.

This requirement is easiest to miss because it rarely appears as a single “cyber rule” in an exam request list. Instead, it shows up as a mismatch: your firm describes a security posture in marketing materials, client communications, DDQs, or responses to due diligence, but your actual controls, monitoring, or incident handling do not support those statements. For SEC-registered investment advisers, that mismatch can become a fraud issue if the statements are materially false or misleading under the Advisers Act advertising framework. (17 CFR 275.206(4)-1)

Operationally, you should treat cybersecurity disclosures as controlled content with the same rigor you apply to performance advertising substantiation. The compliance job is to (1) identify what you say about cybersecurity and incidents, (2) verify you can prove it with current evidence, and (3) ensure incident decisions and external communications follow a documented process with Legal/Compliance sign-off.

The SEC’s Division of Examinations has explicitly stated it will focus on compliance with recently adopted rules including the Marketing Rule. (2025-exam-priorities) Even if your “cyber” program is owned by IT or a CISO, you own the risk that the firm communicates security claims that cannot be substantiated.

Plain-English interpretation (what the requirement means)

If you are an investment adviser and you disseminate an “advertisement,” it is a fraudulent, deceptive, or manipulative act to include an untrue statement of a material fact, or anything otherwise false or misleading. (17 CFR 275.206(4)-1) In practice, cybersecurity and incident disclosure claims can become “advertising” problems when they appear in:

• Website security statements, privacy/cyber pages, or client portal assurances
• Pitch decks, RFPs, DDQs, and diligence questionnaires
• Client letters during or after a cyber event
• Statements about encryption, MFA coverage, monitoring, backups, “SOC 2 compliant,” “no breaches,” “24/7 monitoring,” or “industry-leading security”

So the “cybersecurity risk management and incident disclosure” operational requirement becomes: do not say you have controls, testing, monitoring, or incident response capabilities unless you can prove you do, and do not communicate incident facts until you have a controlled validation and approval process.

Who it applies to (entity and operational context)

Covered entities

• Registered Investment Advisers (RIAs) disseminating advertisements as defined under the SEC Marketing Rule. (17 CFR 275.206(4)-1)

Operational context (where it bites)

• Marketing, investor relations, client service, and sales teams producing security claims
• Security/IT teams implementing controls that must match external statements
• Legal/Compliance teams approving communications, especially post-incident
• Third parties (fund administrators, managed service providers, cloud providers) whose security posture you may describe or rely on in your statements

Regulatory text

Rule excerpt (operator-relevant):
“It shall constitute a fraudulent, deceptive, or manipulative act, practice, or course of business… for any investment adviser to disseminate any advertisement that includes any untrue statement of a material fact, or that is otherwise false or misleading.” (17 CFR 275.206(4)-1)

What you, as the operator, must do with this text

• Identify cybersecurity-related statements that could be “material” to a client or prospective client’s decision.
• Substantiate those statements with current, dated evidence.
• Put a gate in front of publication and incident communications so inaccurate statements do not ship.

What you actually need to do (step-by-step)

1) Build a “cyber claims inventory” (your source of truth)

Create a register of every place the firm makes cybersecurity assertions:

• Website pages, PDFs, pitchbooks, factsheets
• Standard DDQ language, RFP boilerplate, security addenda
• Contract templates and security schedules
• Client portal banners or security FAQs

Output: Cyber Claims Register with fields: statement text, channel, owner, last reviewed date, substantiation link, approval status, and expiration/re-review trigger.

2) Map each claim to a control and an owner (prove the claim is true)

For each claim, write the “control mapping” in plain language:

• Claim: “We enforce MFA for all remote access.”
  Mapping: Identity provider policy + conditional access config + access review evidence + exception process.

Assign a named control owner (IT/Sec) and a content owner (Marketing/IR/Client Service). Require both to sign off at each review.

Good practice control: Maintain a written cybersecurity governance standard mapped to disclosed practices, with named control owners and review cadence.

3) Put pre-publication approval in your marketing workflow

You need a repeatable workflow that blocks unsubstantiated cyber language. Minimum gates:

• Compliance review for misleadingness and required substantiation
• Security/IT review for technical accuracy
• Legal review for incident-specific communications and contractual commitments

Tie the workflow to your marketing rule processes because the SEC has stated continued exam focus on Marketing Rule compliance. (2025-exam-priorities)

4) Establish an incident triage + disclosure decision log

You need a written incident handling procedure that includes:

• Intake and severity triage criteria (what counts as an “incident” for your firm)
• A defined “materiality/disclosure” assessment meeting (who attends, what gets reviewed)
• A controlled facts-validation process (what is confirmed vs. suspected)
• Decision outcomes: notify affected clients, notify regulators where applicable, notify third parties, or hold pending investigation
• A communications approval chain (Security → Legal → Compliance → Executive as needed)

Good practice control: Operate formal incident triage and disclosure-decision logs, including legal/compliance sign-off and evidence retention.

Practical detail that prevents pain: Require every external incident statement to link back to a specific incident record ID and the approved “facts as of” timestamp.

5) Validate controls periodically and track remediation to closure

Cyber claims drift because environments change (new systems, new MSP, new IAM model). Add a validation loop:

• Tabletop exercises for incident communications and approvals
• Targeted testing of controls most often described externally (MFA, encryption, backups, access reviews, monitoring)
• Remediation tracking with due dates and accountable owners

Good practice control: Perform periodic control validation (tabletop or targeted testing) and track remediation to closure.

6) Manage third-party-dependent claims

If your claim depends on a third party (cloud provider, MSP, administrator):

• Document the dependency in the claims register
• Store third-party evidence (attestations, reports, contract security exhibits, service descriptions)
• Avoid absolute statements (“fully secure,” “guaranteed,” “no risk”) and avoid implying you audited a third party if you did not

Required evidence and artifacts to retain

Keep evidence in a system that can survive an exam and a dispute. Minimum artifacts:

• Cyber Claims Register (versioned, dated)
• Marketing/communications approval records (tickets, sign-offs, redlines)
• Substantiation package for each recurring claim:
  • Policies and standards (security, access control, encryption, incident response)
  • Control evidence (config screenshots/exports, access review reports, training records)
  • Testing artifacts (tabletop minutes, test plans, results, remediation tickets)
• Incident artifacts:
  • Incident report, timeline, containment/eradication notes
  • Disclosure decision log with approvals and rationale
  • Copies of client notices and the final approved language
• Third-party due diligence artifacts that support any third-party-related security claims

Common exam/audit questions and hangups

Expect questions that connect marketing statements to operational reality:

• “Show me where your cybersecurity claims are reviewed and approved before dissemination.” (17 CFR 275.206(4)-1)
• “Provide substantiation for this statement in your DDQ / pitchbook / website.”
• “Walk through your last incident: who decided what to disclose, when, and based on which facts?”
• “How do you ensure old RFP boilerplate and website statements stay current?”
• “Which third parties materially support your security program, and what evidence do you keep?”

Hangups that stall teams:

• No single owner for DDQ boilerplate
• Security evidence exists but is not packaged to match specific claims
• Incident comms happen in email/Slack with no durable decision log

Frequent implementation mistakes and how to avoid them

• Mistake: Treating DDQs and RFP responses as “not marketing.”
  Fix: Route all client/prospect cyber statements through the same substantiation workflow used for advertisements. (17 CFR 275.206(4)-1)

• Mistake: Absolute language (“we prevent all breaches,” “we are fully compliant”).
  Fix: Require Compliance to flag absolutes; replace with precise, provable statements tied to specific controls and scope.

• Mistake: Stale claims after an environment change.
  Fix: Add re-review triggers: new IAM, new MSP, new email security stack, M&A, new client portal.

• Mistake: Incident communications sent before facts are validated.
  Fix: Enforce “facts as of” timestamps and a standard approval chain; keep a decision log with rationale.

Enforcement context and risk implications

Even without a single “cyber disclosure rule” cited here, the risk pathway is straightforward: if cybersecurity assurances are materially false or misleading in an advertisement, the SEC can treat that as a prohibited act for an adviser. (17 CFR 275.206(4)-1) Separately, exam teams have stated they will focus on Marketing Rule compliance. (2025-exam-priorities) That combination makes cyber claims a repeat exam and enforcement tripwire because they are easy to sample, and they often lack substantiation discipline.

Practical execution plan (30/60/90)

You asked for speed. Use this phased plan; adjust sequencing based on current maturity.

First 30 days (stabilize claims and approvals)

• Build Cyber Claims Register covering top channels: website, standard DDQ, pitch deck, top RFP templates.
• Freeze new cyber language unless it goes through Security + Compliance approval.
• Identify the top recurring claims and collect substantiation evidence for each.
• Stand up an incident disclosure decision log template and require its use immediately for any event.

By 60 days (prove, test, and train)

• Complete mapping of each claim to a control owner and evidence location.
• Run one tabletop focused on incident communications approvals and “facts validation.”
• Train Marketing/IR/Client Service on what needs approval and what language is prohibited (absolutes, scope creep, third-party overstatements).
• Review third-party-dependent claims; align contracts, due diligence files, and claim language.

By 90 days (operationalize and audit-proof)

• Add periodic control validation to the compliance calendar and track remediation in a ticketing system.
• Implement version control and expiry/review dates for DDQ boilerplate and website claims.
• Perform a self-audit: select a sample of cyber claims and prove substantiation end-to-end, including approvals and evidence.

Where Daydream fits (without adding process overhead)

Daydream is useful when you need a single place to (1) inventory cyber and incident disclosure claims, (2) tie each claim to controls and owners, and (3) store substantiation and approval artifacts so you can answer exam requests quickly without rebuilding the story from scattered systems.

Frequently Asked Questions

Does this apply only to my website marketing materials?

No. Any disseminated “advertisement” content that includes cybersecurity statements can create risk if it is materially false or misleading. (17 CFR 275.206(4)-1) In practice, DDQs, pitch decks, and RFP responses often create the biggest exposure because they include detailed security assertions.

Our CISO owns cybersecurity. Why is Compliance involved?

The rule risk is about what the firm communicates externally. Compliance should own the approval and substantiation workflow, while Security owns control operation and evidence production. (17 CFR 275.206(4)-1)

What evidence is “enough” to substantiate a cybersecurity claim?

Evidence should be specific, current, and tied to the exact claim language. A policy alone rarely suffices; pair it with operational proof like configuration exports, access review outputs, or testing results, stored with dates and owners.

How do we handle third-party security statements in DDQs?

Document what you rely on (attestations, contract terms, service descriptions) and avoid implying you performed audits you did not. Keep third-party artifacts attached to the claim in the register so the substantiation survives staff turnover.

What should be logged during an incident if we’re not sure it’s material yet?

Log the timeline, known facts vs. hypotheses, attendees, decisions, and the basis for each decision. Keep the approval record for any external communication, even if the decision is to delay messaging pending investigation.

Can we say “SOC 2 compliant” if we have a SOC 2 report?

Treat it as a scoped statement: confirm the report type, period covered, and which entity/system it applies to. Store the report (or permitted extracts) and approval record with the exact language you publish.