Cybersecurity Policies and Incident Disclosure Requirements
To meet cybersecurity policies and incident disclosure requirements requirement expectations as an SEC-registered investment adviser, you must (1) maintain written cybersecurity policies that match what you tell clients, (2) run periodic risk assessments and control testing, and (3) document incident triage and disclosure decisions so your communications are not false or misleading under the SEC’s Marketing Rule. 1
Key takeaways:
- Your cybersecurity statements in pitch decks, RFIs, websites, and DDQs are “advertisements” risk; they must be accurate, current, and supportable. 1
- Operationalize incident disclosure with a documented materiality and disclosure decision workflow, plus evidence retention.
- Exams continue to prioritize Marketing Rule compliance, so expect testing of substantiation, governance, and review controls. 2
“Cybersecurity policies and incident disclosure requirements” sounds like an infosec-only topic until you map it to the SEC’s core expectation for advisers: do not say things to clients and prospects that are untrue, incomplete, or misleading. Under the SEC’s Marketing Rule, cybersecurity claims can become a compliance issue the moment they appear in an RFP response, diligence questionnaire, pitch deck, website, factsheet, or client letter. 1
For a CCO or GRC lead, the fastest path is to treat cybersecurity representations as regulated communications that require governance, review, and substantiation. That means your written cybersecurity policies, risk assessments, and incident response/disclosure playbooks must align with what sales and investor relations actually say. It also means you need a repeatable process to triage incidents, decide what is “material” for disclosure purposes, and document why you did or did not disclose, including Compliance and Legal sign-off.
This page gives requirement-level implementation guidance you can put into production: who is in scope, what to build, what evidence to keep, where audits/exams snag teams, and an execution plan you can run without waiting for a perfect security program.
Regulatory text
Rule driver (Marketing Rule). The SEC rule text you must operationalize here is the prohibition on false or misleading statements in adviser advertisements: “It shall constitute a fraudulent, deceptive, or manipulative act… for any investment adviser to disseminate any advertisement that includes any untrue statement of a material fact, or that is otherwise false or misleading.” 1
Operator meaning. If you state or imply cybersecurity capabilities, controls, incident history, monitoring, response times, third-party oversight, or breach disclosure practices in any “advertisement,” you must be able to substantiate it and keep it current. Any mismatch between:
- written cybersecurity policies vs. actual practices,
- incident handling vs. what you told clients you would do,
- “no incidents” claims vs. your incident logs, can create Marketing Rule exposure. 1
Exam context. The SEC Division of Examinations stated it will focus on compliance with recently adopted SEC rules including the Marketing Rule. Plan for exam questions that connect cybersecurity claims to substantiation and oversight controls. 2
Plain-English interpretation (what the requirement demands)
You need a defensible system that ensures cybersecurity policies exist, are periodically reviewed against real risk, and that any incident-related disclosures (or decisions not to disclose) follow a consistent process. The compliance objective is not “perfect security.” The compliance objective is “no false or misleading cybersecurity communications,” backed by governance and records. 1
This requirement becomes urgent in three common moments:
- Fundraising / new client onboarding: DDQs and pitch decks contain broad cybersecurity claims.
- After an event: operational teams scramble and communications drift from facts.
- During an exam: examiners ask for substantiation, approvals, and incident history.
Who it applies to (entity + operational context)
Entities in scope: SEC-registered investment advisers and their supervised persons who create, approve, or disseminate advertisements. 1
Operational contexts that create risk:
- RFP/RFI responses, DDQs, and due diligence portals
- Pitchbooks, tear sheets, websites, market commentary that includes cyber statements
- Client communications about operational resilience, business continuity, or security
- Third-party oversight statements (cloud providers, SOC reports, penetration tests)
- Incident notices, “we experienced an event” letters, and post-incident FAQs
What you actually need to do (step-by-step)
1) Build a single source of truth for cybersecurity claims
Create an inventory of every place your firm makes cybersecurity or incident-disclosure statements:
- Website pages (security, privacy, BCP summaries)
- Pitch decks and factsheets
- DDQ templates (including investor-specific portals)
- Standard contractual language (MSAs, side letters, security addenda)
- RFP response libraries
Output: a “Cybersecurity Claims Register” with fields: statement, channel/document, owner, last reviewed date, substantiation link, and approved wording.
2) Map claims to written policies and real controls
For each claim, map to:
- a policy section (information security policy, incident response plan, vendor/third-party risk, access control standard),
- an operating procedure (ticket workflow, alerting, approvals),
- evidence (logs, test results, training completion, configuration baselines).
If you cannot support a claim today, either (a) remediate the control gap, or (b) change the claim to a narrower, accurate statement. Under the Marketing Rule, the risk is the statement, not the intention. 1
3) Implement a periodic cyber risk assessment and control validation cadence
You need a repeatable method to reassess risk and validate that “paper controls” work in practice. Use an established framework to structure it (pick one and stick to it):
- NIST Cybersecurity Framework (CSF) for outcomes-based control mapping
- ISO/IEC 27001 for policy and control governance structure
- CIS Controls for pragmatic technical measures
Minimum operational expectation: document the assessment scope, key risks, control gaps, and remediation owners; track remediation to closure. This is the easiest way to keep your external statements aligned with your current posture.
4) Operationalize incident triage and disclosure decisioning
Create an “Incident Triage + Disclosure Decision” workflow that Compliance can run with Security and Legal:
A. Define “incident” for internal tracking Use an internal definition broad enough to capture events that might later matter for disclosure decisions (for example: unauthorized access, malware, data exfil suspicion, third-party compromise affecting your environment).
B. Establish a materiality/disclosure decision rubric Do not rely on memory during an event. Predefine decision factors and required sign-offs. Example rubric dimensions:
- Client impact (availability, confidentiality, integrity)
- Data involved (client data, MNPI indicators, credentials)
- Duration and containment status
- Regulatory/contractual notification triggers in client agreements
- Third-party involvement and dependency concentration
- Ability to substantiate statements made so far
C. Require a written decision record For every potentially reportable event, keep a disclosure decision memo or log entry with:
- timeline (detection, containment, investigation milestones),
- what was known at decision time,
- disclosure decision and rationale,
- who approved (Security lead, Legal, CCO),
- client/regulator communications issued (or not issued), with versions.
This is the control that prevents inconsistent or overstated messaging, which can become misleading advertising or misleading client communications. 1
5) Put cybersecurity statements under marketing compliance review
Treat cybersecurity claims like performance claims: pre-review, approval, and version control. Integrate into your Marketing Rule workflow:
- Pre-approve standardized cyber language blocks for DDQs and pitch decks
- Route non-standard requests to Compliance + Security for substantiation
- Use a change-control trigger: policy updates, major tool changes, or incidents require a review of external language within your communications library
The SEC has signaled that Marketing Rule compliance remains an exam focus, so governance evidence matters. 2
6) Add third-party evidence handling (without overpromising)
If you cite SOC reports, penetration tests, or certifications in diligence materials:
- store the reports securely,
- track expiration dates,
- limit distribution per NDA,
- ensure your claims match the report scope and period.
Common trap: citing a third party’s SOC report as if it covers your firm’s environment end-to-end.
Required evidence and artifacts to retain
Keep records in a system your exam response team can search quickly.
Governance + policy
- Information security policy set (approved versions, review history)
- Incident response plan + escalation matrix
- Cybersecurity governance standard (control owners, review cadence)
- Security awareness training materials and completion evidence (if claimed externally)
Risk assessment + testing
- Periodic cyber risk assessment reports (scope, findings, remediation tracking)
- Tabletop exercise reports and after-action items
- Targeted control test results (access reviews, backups restore tests, logging checks)
- Remediation tracker with owners and closure evidence
Marketing/communications substantiation
- Cybersecurity Claims Register
- Substantiation pack for each material claim (screenshots, configs, tickets, reports)
- Marketing/Compliance approvals for cybersecurity language blocks
- Version history of DDQ standard responses and pitchbook “Operations / Security” slides
Incident handling + disclosure
- Incident register (including near misses if tracked)
- Triage notes, forensics summaries (as available), containment actions
- Disclosure decision memos/logs with Legal/Compliance sign-off
- Client notification templates, issued notices, FAQs, and distribution lists
Common exam/audit questions and hangups
Expect questions that connect your external statements to internal reality:
-
“Show me substantiation for the cybersecurity statements in this pitch deck/DDQ.” 1
Hangup: teams have policies but no evidence bundle mapped to each claim. -
“How do you review and approve cybersecurity-related advertising statements?” 1
Hangup: marketing review exists for performance/strategy, but not for cyber statements. -
“Walk us through the last incident. Who decided what to disclose?”
Hangup: the decision was made in chats and calls with no durable record. -
“How do you ensure statements remain current after control changes or tool migrations?”
Hangup: no trigger that forces DDQ library updates after operational changes. -
“Is the Marketing Rule part of your exam readiness planning?” 2
Hangup: cybersecurity is treated as “IT,” not Marketing Rule scope.
Frequent implementation mistakes (and how to avoid them)
-
Mistake: “No breaches” claims without a defined incident threshold.
Fix: define “incident” for internal logging and restrict external phrasing to what you can defend with records. 1 -
Mistake: Overbroad claims copied from templates (“we monitor 24/7,” “encrypted everywhere”).
Fix: require substantiation links in the Claims Register and remove claims that lack an owner and evidence. -
Mistake: Incident disclosure handled as ad hoc PR.
Fix: require a disclosure decision log entry for every serious event, even if you decide “no client notice.” -
Mistake: Third-party controls presented as your controls.
Fix: clearly scope statements (“our cloud provider maintains…”) and keep the underlying reports on file. -
Mistake: Policies updated annually, DDQs updated never.
Fix: institute a change-control trigger that forces cybersecurity language review after significant incidents and major environment changes.
Enforcement context and risk implications (what’s at stake)
You do not need an enforcement case to see the exposure: the cited SEC rule frames false or misleading advertisements as “fraudulent, deceptive, or manipulative.” Cybersecurity statements often become “material” to client decisions, especially in institutional due diligence. If an incident occurs, prior overstatements about response time, monitoring, or disclosure practices can compound regulatory risk because your communications history becomes part of the fact pattern. 1
Practical 30/60/90-day execution plan (operator-ready)
You asked for speed. Use phases, not promises.
First 30 days (stabilize claims + decisioning)
- Stand up a Cybersecurity Claims Register for your top client-facing documents (DDQ template, pitchbook, website security language).
- Pre-approve standard cybersecurity language blocks; route exceptions to Compliance + Security for substantiation. 1
- Draft the incident triage + disclosure decision workflow and require a disclosure decision log entry for any significant event going forward.
Days 31–60 (prove it with evidence + testing)
- Build substantiation packs for each high-risk claim (monitoring, encryption, access control, IR timelines, third-party oversight).
- Run a tabletop exercise focused on “incident + client disclosure decision,” then document after-action remediation.
- Implement a remediation tracker tied to the risk assessment and tabletop findings.
Days 61–90 (institutionalize governance)
- Add cybersecurity statements to your formal marketing review checklist and QA sampling.
- Implement change-control triggers (tooling changes, policy updates, incidents) that require updates to DDQ libraries and pitchbook security slides.
- Prepare an exam-ready binder: policies, risk assessments, claims register, substantiation, incident logs, disclosure decision memos, and approvals. 2
Where Daydream fits (practitioner use case): Daydream becomes useful once you’ve defined the claims register and evidence list. It helps you keep requirements and artifacts tied together so your DDQ language, marketing approvals, and incident decision records stay consistent across teams during exams and client diligence.
Frequently Asked Questions
Are DDQs and RFP responses treated like “advertisements” under the SEC Marketing Rule?
They can be, depending on how they are used and disseminated, and they create the same practical risk: a false or misleading cybersecurity statement can violate the rule. Treat DDQ/RFP cybersecurity responses as regulated communications that require substantiation and approval. 1
Do we need to disclose every cybersecurity incident to clients?
The requirement to operationalize here is that your disclosure practices must match what you say and must not be misleading. Build a documented triage and disclosure decision process, then ensure your external statements describe that process accurately. 1
What evidence should we keep for “we monitor continuously” type statements?
Keep whatever proves the claim in practice: monitoring tool configurations, alerting rules, SOC runbooks, and tickets showing triage and escalation. Link those artifacts directly to the statement in your Claims Register.
Who should approve incident disclosure decisions?
Set required sign-offs in your workflow: Security for facts and containment status, Legal for notification obligations and privilege considerations, and the CCO (or delegate) for client communication consistency and marketing rule risk. 1
How do we keep cybersecurity language current across many client templates?
Maintain standardized language blocks and a single controlled DDQ response library with version history. Add change-control triggers so significant incidents, tooling changes, or policy updates prompt a review of external statements.
What’s the fastest way to get exam-ready on this topic?
Build an exam binder organized around the rule: advertisements containing cyber statements, substantiation for each material statement, your incident triage/disclosure decision logs, and evidence of periodic risk assessment and testing. Expect Marketing Rule attention in exams. 2
Footnotes
Frequently Asked Questions
Are DDQs and RFP responses treated like “advertisements” under the SEC Marketing Rule?
They can be, depending on how they are used and disseminated, and they create the same practical risk: a false or misleading cybersecurity statement can violate the rule. Treat DDQ/RFP cybersecurity responses as regulated communications that require substantiation and approval. (Source: 17 CFR 275.206(4)-1)
Do we need to disclose every cybersecurity incident to clients?
The requirement to operationalize here is that your disclosure practices must match what you say and must not be misleading. Build a documented triage and disclosure decision process, then ensure your external statements describe that process accurately. (Source: 17 CFR 275.206(4)-1)
What evidence should we keep for “we monitor continuously” type statements?
Keep whatever proves the claim in practice: monitoring tool configurations, alerting rules, SOC runbooks, and tickets showing triage and escalation. Link those artifacts directly to the statement in your Claims Register.
Who should approve incident disclosure decisions?
Set required sign-offs in your workflow: Security for facts and containment status, Legal for notification obligations and privilege considerations, and the CCO (or delegate) for client communication consistency and marketing rule risk. (Source: 17 CFR 275.206(4)-1)
How do we keep cybersecurity language current across many client templates?
Maintain standardized language blocks and a single controlled DDQ response library with version history. Add change-control triggers so significant incidents, tooling changes, or policy updates prompt a review of external statements.
What’s the fastest way to get exam-ready on this topic?
Build an exam binder organized around the rule: advertisements containing cyber statements, substantiation for each material statement, your incident triage/disclosure decision logs, and evidence of periodic risk assessment and testing. Expect Marketing Rule attention in exams. (Source: 2025-exam-priorities)
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream