Summary. Regulators no longer ask whether a company has security; they ask to see the documents that prove a program exists, works, and is overseen. This guide walks through building that program in ten chronological steps: scoping the regimes that apply, appointing accountable people, conducting the written risk assessment, writing the policies, implementing the controls examiners check first, managing vendors, training and testing, building an incident response plan mapped to every reporting clock, reporting to the board and certifying, and preparing for examinations and investigations. Each step identifies the governing requirements under the FTC Act and Safeguards Rule, NYDFS Part 500, the SEC's disclosure rules, HIPAA, CMMC, and state law, together with the evidence a regulator will request and the decisions the company must make. It closes with a realistic twelve-month timeline and cost ranges, common mistakes, a worked example of a New York-licensed online lender building its program from a standing start, an FAQ, and practical takeaways for compliance teams, boards, and the lawyers who advise or examine them.


The letter from the regulator is two pages long, and the second page is a list. Produce your most recent written risk assessment. Produce your information security policies and the dates they were approved. Produce the reports your chief information security officer gave the board for the last two years, your last penetration test, the tracker showing how its findings were fixed, your vendor inventory, and your incident response plan with the record of the last time you tested it.

Nothing on that list asks whether the company was hacked, and nothing asks whether its security was "good." The list is a test of whether a program exists on paper, operates in fact, and is overseen by people with authority. A company that can produce every item within two weeks is usually in a negotiation. A company that has to create the items after the letter arrives is in trouble.

The short answer

A cybersecurity program "satisfies regulators" when it can prove five things with documents: that the company identified the rules that apply and the data and systems they protect; that named people with real authority run the program and answer for it; that the controls rest on a written risk assessment and are actually implemented, tested, and fixed when tests fail; that the company oversees its vendors; and that the board receives written reports and the company can detect, respond to, and report incidents on every applicable clock.

Build it in this order:

  1. Scope the program: the regimes, data, systems, vendors, and jurisdictions.
  2. Appoint the accountable people: a Qualified Individual or CISO, a senior overseer, and a board committee.
  3. Conduct the written risk assessment and produce a risk register.
  4. Write the program documents: the written information security program (WISP), policies, and standards.
  5. Implement the controls examiners check first: MFA, encryption, access control, asset inventory, logging, patching, backups, and data disposal.
  6. Bring vendors under the program.
  7. Train people and test the controls.
  8. Write and exercise an incident response plan that maps every reporting clock.
  9. Report to the board in writing, certify where required, and align public disclosures.
  10. Prepare for examinations and investigations, and keep the evidence file current.

A mid-size company starting from a weak base should expect the first full cycle to take nine to eighteen months, and should expect to spend real money on people and testing. The rest of this guide explains each step, the legal requirement behind it, the evidence it produces, and the decisions along the way. For the substantive law in depth, see the companion article, Cybersecurity Regulation for Businesses: The FTC Safeguards Rule, NYDFS Part 500, SEC Cyber Disclosure, and State Laws.

The legal framework you are building to

Every regime below requires a program, and every one of them is enforced by asking for evidence. The table pairs each source of law with the program documents an examiner will expect.

Source of law Core program requirement Documents an examiner will ask for
FTC Act § 5, 15 U.S.C. § 45 "Reasonable" security; no deceptive security claims Policies, risk assessments, public security statements and their substantiation
GLBA Safeguards Rule, 16 C.F.R. Part 314, under 15 U.S.C. § 6801 Written program with Qualified Individual, written risk assessment, enumerated controls, testing, vendor oversight, incident plan, annual board report Each of those documents, plus FTC notices filed for notification events
NYDFS, 23 NYCRR Part 500 CISO, board oversight, risk assessment, prescriptive controls, Class A extras, annual certification Certification and supporting documentation, policies approved annually, audit and testing reports, 72-hour and 24-hour notices
HIPAA Security Rule, 45 C.F.R. Part 164, Subpart C Enterprise-wide risk analysis, risk management, safeguards, business associate agreements Risk analysis and risk management plan, policies retained for six years, BAAs, activity reviews
SEC Regulation S-K Item 106, 17 C.F.R. § 229.106, and Form 8-K Item 1.05 Disclose risk management, governance, and material incidents Disclosure committee records, materiality memos, board and committee minutes
SEC Regulation S-P, 17 C.F.R. Part 248 Written safeguards, incident response program, customer notice, service provider oversight Policies, incident records, service provider contracts and monitoring files
State law (201 CMR 17.00; N.Y. Gen. Bus. Law § 899-bb; Cal. Civ. Code § 1798.81.5) WISP or reasonable safeguards WISP, training records, vendor contracts
DFARS 252.204-7012 and CMMC, 48 C.F.R. Part 252; 32 C.F.R. Part 170 NIST SP 800-171 controls, incident reporting, assessment and affirmation System security plan, plans of action and milestones, assessment scores, affirmations

What the cases say a program must look like

The case law gives the program its shape more than its content.

Step 1: Scope the program

Goal: a written applicability analysis that says which laws, contracts, and frameworks govern which entities, data, and systems. Owner: legal and compliance, with security. Time: two to six weeks.

1.1 Identify the regimes

Work through four questions, and write the answers down.

  1. What licenses and registrations does each entity hold? A New York banking, insurance, or money transmitter license brings in Part 500. An insurance license in a state that adopted the NAIC model law brings in that statute. SEC registration as a broker-dealer or adviser brings in Regulation S-P. A listed security brings in Item 106 and Item 1.05.
  2. What data does the company hold, and about whom? Nonpublic personal information from financial products triggers the GLBA rules; protected health information triggers HIPAA (or, for apps outside HIPAA, the FTC's Health Breach Notification Rule, 16 C.F.R. Part 318); payment card data triggers PCI DSS through the merchant agreement; controlled unclassified information triggers DFARS; and personal information collected online from children under 13 now requires a written information security program under the amended COPPA Rule, 16 C.F.R. § 312.8.
  3. Where do the people whose data you hold live? Massachusetts residents bring in 201 CMR 17.00, New York residents the SHIELD Act, and California residents § 1798.81.5 and the § 1798.150 private right of action.
  4. What have you promised? Customer contracts, data processing agreements, business associate agreements, security questionnaires, SOC 2 commitments, cyber insurance applications, and every public statement about security are obligations too. The FTC treats unkept security promises as deception under 15 U.S.C. § 45(a).

Do not forget sector rules that sit outside the usual compliance radar: the banking agencies' 36-hour incident notice rule, 12 C.F.R. Part 53, for banks and their service providers; the NCUA's 72-hour rule, 12 C.F.R. Part 748, for credit unions; the FCC's CPNI rules, 47 U.S.C. § 222, for carriers; NERC CIP standards, 18 C.F.R. Part 40, for the grid; and TSA's directives and rules, such as 49 C.F.R. Part 1582, for transit and rail.

1.2 Map data and systems

Regulators increasingly require an inventory, and the program cannot be scoped without one. The Safeguards Rule requires the institution to "identify and manage the data, personnel, devices, systems, and facilities" that matter to its business. 16 C.F.R. § 314.4(c)(2). Part 500 requires a written asset inventory. Build three linked lists: systems (on-premises, cloud, SaaS, operational technology), data stores (what categories of data sit where), and data flows (where data moves, including to vendors). Mark the "crown jewels," the systems whose compromise would be material.

1.3 Decide the structure

Decision point: one program or several? Most companies should run one enterprise program built to the most prescriptive applicable regime, with annexes for regime-specific items (the HIPAA business associate inventory, the Part 500 certification process, the CMMC system security plan). Separate programs for separate legal entities make sense only where systems are genuinely separate. If affiliates share email, identity, or networks, Part 500 and the Safeguards Rule will treat a compromise of the shared system as the covered entity's problem.

1.4 Choose the framework and build the crosswalk

Choose a framework to organize the work, not to satisfy a statute. NIST CSF 2.0, released in February 2024, is the most common choice because its six functions (Govern, Identify, Protect, Detect, Respond, Recover) map onto every regime. The CIS Critical Security Controls (version 8.1) are better for deciding what to implement first, through their implementation groups. ISO/IEC 27001 and SOC 2 matter where customers demand certification or attestation. Defense contractors have no choice: NIST SP 800-171 governs controlled unclassified information.

Then build a crosswalk: a spreadsheet in which each row is a legal requirement (for example, § 314.4(c)(5), MFA), with columns for the corresponding Part 500 section, HIPAA specification, framework control, policy that implements it, system owner, and evidence location. The crosswalk is the single most useful document in an examination, because it lets the company answer "how do you meet this?" in one line.

Outputs of Step 1: the regulatory applicability memo, the asset and data inventory, the structure decision, and the crosswalk.

Step 2: Appoint the accountable people

Goal: named individuals with documented authority and reporting lines. Owner: CEO and board. Time: two to eight weeks, longer if hiring.

2.1 The program lead

Every regime requires a named person: the Qualified Individual under the Safeguards Rule, 16 C.F.R. § 314.4(a); the CISO under Part 500; the security official under the HIPAA Security Rule, 45 C.F.R. § 164.308(a)(2); the employee who coordinates the program under 201 CMR 17.00 and the amended COPPA Rule. One person can fill all of these roles, and usually should.

Decision point: hire or outsource? A full-time CISO is right for companies with complex environments, regulated data at scale, or Class A status under Part 500. A "virtual" CISO from a security firm is common and legitimate for smaller institutions, but the rule imposes conditions: under § 314.4(a), the institution keeps responsibility, must designate a senior member of its own personnel to direct and oversee the outsourced individual, and must require the provider to maintain a program that protects the institution. Avoid having the managed IT provider supply the vCISO who then oversees that same provider's work; examiners notice self-review.

Give the lead real authority. Part 500 requires that the CISO have "adequate authority" to manage cyber risk, including the ability to direct sufficient resources. A CISO who reports to the CIO, whose budget and uptime goals sometimes conflict with security, should also have a direct line to the CEO, general counsel, or a board committee. Write the authority into an appointment letter or board resolution.

2.2 The board and its committee

Decide which committee owns cyber oversight (audit, risk, or a dedicated technology committee), amend its charter to say so, and set a calendar: at least an annual written report from the program lead, more frequent updates (quarterly is typical), and immediate escalation criteria for significant incidents. Part 500 requires the board to have "sufficient understanding of cybersecurity-related matters to exercise such oversight," which in practice means director education and access to outside advisers. Public companies must describe this oversight in the 10-K under Item 106(c), so the structure you build is also the structure you disclose. The fiduciary background is in Fiduciary Duties of Directors and Officers: The Business Judgment Rule, Loyalty, and Caremark Oversight.

2.3 The management layer

Create a security steering committee with the program lead, IT, legal, privacy, compliance, HR, finance, and the owners of the most important business systems. Give it a charter and keep minutes. Its job is to make the risk decisions that the program lead should not make alone, particularly decisions to accept risk. Officers matter here too: the Delaware Court of Chancery has held that officers owe oversight duties within their areas of responsibility (In re McDonald's Corp. Stockholder Derivative Litigation, 289 A.3d 343 (Del. Ch. 2023)), so a CIO or CISO of a Delaware company has personal exposure for ignoring red flags in security.

Outputs of Step 2: appointment letter or resolution, job description, committee charters, an organization chart, and a responsibility matrix (who is responsible, accountable, consulted, and informed for each control family).

Step 3: Conduct the written risk assessment

Goal: a written assessment that leads to decisions, and a risk register that tracks them. Owner: the program lead, with system owners. Time: four to ten weeks for the first one.

3.1 What the law requires

The requirements are similar and cumulative. The Safeguards Rule requires a written assessment that includes criteria for evaluating and categorizing risks, criteria for assessing confidentiality, integrity, and availability, and requirements describing how each risk will be mitigated or accepted, followed by periodic reassessment. 16 C.F.R. § 314.4(b). Part 500 requires an assessment that is reviewed and updated at least annually and whenever a change in the business or technology causes a material change in cyber risk. The HIPAA Security Rule requires "an accurate and thorough assessment of the potential risks and vulnerabilities" to electronic protected health information, across the enterprise. 45 C.F.R. § 164.308(a)(1)(ii)(A). OCR cites a missing or incomplete risk analysis in most of its security settlements; see HIPAA Security Rule Risk Analysis Checklist: A Practical Checklist.

3.2 How to do it

  1. Start from the inventory. An assessment that does not cover every system holding regulated data is the most common defect regulators find.
  2. Identify threats realistically. Ransomware, business email compromise, credential theft, cloud misconfiguration, vendor compromise, insider misuse, and social engineering that now uses AI-generated voices and text. NYDFS issued guidance in 2024 on AI-related cyber risks, and it works well as a checklist for this part of the assessment.
  3. Identify vulnerabilities from evidence, not memory: scan results, penetration test findings, audit reports, prior incidents, and the gap analysis against the crosswalk.
  4. Rate likelihood and impact using written criteria (a five-point scale is common; quantitative methods such as FAIR are better for prioritizing spending). Record inherent risk, existing controls, and residual risk.
  5. Decide the treatment for each risk: mitigate (with an owner and a due date), transfer (insurance or contract), avoid (stop the activity), or accept. Acceptance must be in writing, by someone with authority to accept it, with a review date.
  6. Report the results to the steering committee and summarize them for the board.

The output is a risk register: a living list of risks with identifiers, owners, ratings, treatments, due dates, and acceptance records. Regulators and plaintiffs read registers line by line. An item that sat "in progress" for two years, with no acceptance, reads as knowledge without action.

3.3 Decision point: what should be privileged?

The required risk assessment is a business record that the law compels you to create; assume it will be produced. Counsel can, however, commission a separate legal assessment of regulatory exposure, under a separate engagement in which counsel directs the work for the purpose of legal advice. Protection depends on the facts. In In re Premera Blue Cross Customer Data Security Breach Litigation, 296 F. Supp. 3d 1230 (D. Or. 2017), the court refused to protect a forensic firm's work merely because supervision shifted to outside counsel after the breach, since the firm's scope of work never changed; it contrasted the two-track approach in Target's breach investigation. The work-product rule is Fed. R. Civ. P. 26(b)(3), and a Fed. R. Evid. 502(d) order can limit waiver when documents are produced in litigation. Write every required document as if a regulator will read it, because one will.

Outputs of Step 3: the written risk assessment, the risk register, the methodology document, and signed risk acceptances.

Step 4: Write the program documents

Goal: a written information security program and a set of policies that describe what the company actually does. Owner: the program lead, with legal. Time: four to eight weeks, in parallel with Step 5.

4.1 The WISP as the umbrella

The written information security program is the document that ties everything together. It should state the program's scope (entities, systems, data), the roles from Step 2, the risk assessment method from Step 3, the list of policies and standards, the training program, the vendor program, the incident response plan, the testing schedule, the retention and disposal rules, the consequences for violations, and the review cycle. The Safeguards Rule allows the program to be "written in one or more readily accessible parts," 16 C.F.R. § 314.3(a), so a short WISP that points to separate policies is fine.

4.2 The policy set

Part 500 lists the subjects the written policies must address, and the list works for any company: information security; data governance, classification, and retention; asset inventory and device management; access controls, remote access, and identity management; business continuity and disaster recovery; systems operations and availability; network security and monitoring; security awareness and training; application security and secure development; physical and environmental security; customer data privacy; vendor management; risk assessment; incident response and notification; and vulnerability management.

Four drafting rules prevent most problems:

  • Write what you do, or what you will do by a stated date. A policy the company does not follow is evidence against it, and in an FTC investigation it can become a deception count.
  • Separate policy from procedure. Policies state requirements and are approved by senior management or the board; standards and procedures change more often and are approved by the program lead.
  • Build an exception process. Every policy needs a way to grant documented, time-limited exceptions. Undocumented exceptions are violations.
  • Approve, date, and keep. Part 500 requires annual approval by a senior officer or the board. HIPAA requires retaining policies and related documentation for six years. Version control lets you prove which policy was in force on the day of an incident.

4.3 Align public statements

The last task in Step 4 is to reconcile what the company says publicly with what the policies say. Review the privacy policy, the security or "trust" page, marketing claims, standard responses to customer security questionnaires, and, for public companies, the risk factors and Item 106 disclosure. The SEC's SolarWinds case was built on a website "Security Statement" that described practices the company allegedly did not follow, and the court let fraud claims based on that statement proceed even as it dismissed most of the others (SEC v. SolarWinds Corp., 741 F. Supp. 3d 37 (S.D.N.Y. 2024)). For drafting public statements that will hold up, see Drafting and Maintaining a Privacy Policy: A Practical Guide.

Outputs of Step 4: the WISP, the approved policy set, the standards and procedures, the exception register, and a reconciled set of public statements.

Step 5: Implement the controls examiners check first

Goal: the controls that regulators, insurers, and plaintiffs test first, implemented and provable. Owner: IT and security, with system owners. Time: three to twelve months, prioritized by risk.

5.1 The priority controls, mapped to the rules

The following table maps the controls that appear in nearly every enforcement action to the main federal and New York requirements. HIPAA citations are to 45 C.F.R. Part 164.

Control Safeguards Rule (16 C.F.R.) NYDFS Part 500 HIPAA Security Rule Evidence to keep
Multi-factor authentication § 314.4(c)(5) § 500.12 § 164.312(d) (authentication) MFA coverage report; written approvals of any exception
Encryption in transit and at rest § 314.4(c)(3) § 500.15 § 164.312(a)(2)(iv), (e)(2)(ii) Configuration exports; key management records
Access control and least privilege § 314.4(c)(1) § 500.7 § 164.308(a)(4); § 164.312(a) Access reviews; privileged access logs; termination checklists
Asset inventory § 314.4(c)(2) § 500.13(a) Risk analysis scope The inventory, with update dates
Logging and monitoring § 314.4(c)(8) § 500.14 § 164.312(b); § 164.308(a)(1)(ii)(D) Log sources; alert review records
Vulnerability management and testing § 314.4(d) § 500.5 § 164.308(a)(8) (evaluation) Scan reports; penetration tests; remediation tracker
Secure development § 314.4(c)(4) § 500.8 Not specified SDLC policy; code review and testing records
Backups and recovery § 314.4(h) (plan) § 500.16 § 164.308(a)(7) Restore test results; offline or immutable copies
Retention and disposal § 314.4(c)(6) § 500.13(b) § 164.310(d)(2)(i) Retention schedule; destruction records
Change management § 314.4(c)(7) Policy area under § 500.3 Not specified Change tickets and approvals
Training § 314.4(e) § 500.14(a)(3) § 164.308(a)(5) Completion records; phishing simulation results

5.2 How to prioritize

If resources are limited, and they always are, sequence the work by how attacks actually succeed:

  1. MFA on every remote, email, cloud administration, and privileged access path, with phishing-resistant methods (hardware keys or platform authenticators) for administrators. The Safeguards Rule and Part 500 now require MFA for essentially everyone, and the FTC's recent orders specify phishing-resistant MFA for sensitive access.
  2. Patch internet-facing systems fast, prioritizing vulnerabilities known to be exploited in the wild. CISA's Known Exploited Vulnerabilities catalog is the practical priority list.
  3. Endpoint detection and response on servers and workstations, with someone watching the alerts around the clock (in-house or a managed provider). Part 500 requires it for Class A companies.
  4. Immutable or offline backups, tested by actually restoring them.
  5. Segmentation, so a compromised workstation cannot reach the databases holding regulated data.
  6. Logging that is retained long enough to investigate an intrusion that began months before it was found, and reviewed by someone.
  7. Data minimization: delete what you do not need. The Safeguards Rule's two-year disposal default, 16 C.F.R. § 314.4(c)(6), and the FTC's orders against Drizly and Blackbaud make over-retention a violation theory of its own.

5.3 Exceptions and compensating controls

Both the Safeguards Rule and Part 500 allow alternatives to MFA and encryption only with written approval by the Qualified Individual or CISO (Part 500 also requires annual review of those approvals). Keep a register of every such approval with the reason, the compensating control, and the expiration date. An unregistered exception, discovered after an attacker used it, is the scenario every regulator's order is designed to punish.

5.4 Build the evidence library as you go

For each control, decide now what evidence proves it operates: a monthly MFA coverage export, quarterly access review sign-offs, scan reports, restore test results. Store the evidence where the crosswalk says it is. Companies that collect evidence continuously spend weeks, not months, answering an examination request.

Outputs of Step 5: implemented controls, the exception register, and the evidence library.

Step 6: Bring vendors under the program

Goal: every vendor that touches regulated data or critical systems identified, assessed, contracted, and monitored. Owner: procurement and legal, with security. Time: the first pass takes three to six months; it never ends.

6.1 The legal hooks

The Safeguards Rule requires selecting capable service providers, requiring safeguards by contract, and periodically assessing them. 16 C.F.R. § 314.4(f). Part 500 requires a written third-party service provider policy covering identification, risk assessment, minimum practices, due diligence, and periodic assessment, with contract terms addressing access controls, encryption, and prompt notice of cybersecurity events. HIPAA requires business associate agreements, and since the HITECH Act business associates are directly liable for Security Rule compliance. 42 U.S.C. § 17931; 45 C.F.R. § 160.103. Regulation S-P now requires policies under which service providers notify the firm within 72 hours of a breach affecting customer information systems. DFARS 252.204-7012 must be flowed down to subcontractors that handle covered defense information. Public companies must say in Item 106 whether they have processes to oversee third-party risks.

6.2 The process

  1. Inventory and tier. List every vendor with access to regulated data, network access, or operational importance. Tier them (critical, high, moderate, low) by data sensitivity and business impact.
  2. Diligence proportionate to tier. For critical vendors, obtain a current SOC 2 Type II report or ISO/IEC 27001 certificate, read the exceptions and the "complementary user entity controls" the vendor expects you to run, and ask for penetration test summaries. For lower tiers, a questionnaire may be enough.
  3. Contract terms. A security exhibit with specific controls (MFA, encryption, logging), incident notice within a fixed number of hours (24 to 72 is common, and it must be shorter than your own regulatory clocks), cooperation and access to forensic information, audit rights, subcontractor flow-down, data return and deletion at termination, insurance, and allocation of breach costs. Read the limitation-of-liability clause with breach costs in mind; in Schnuck Markets, Inc. v. First Data Merchant Services Corp., 852 F.3d 732 (8th Cir. 2017), a $500,000 cap in a payment processing agreement decided who paid for millions of dollars in card-network assessments.
  4. Monitor. Reassess critical vendors at least annually, watch for incidents and ownership changes, and track open findings.
  5. Plan for concentration. The 2024 Change Healthcare ransomware attack and the July 2024 outage caused by a faulty CrowdStrike software update both showed how one vendor's failure can halt thousands of customers. Business continuity planning must assume a critical vendor will be unavailable.
  6. Offboard. Revoke access and obtain certification of data return or deletion.

For the full vendor process, see Building a Vendor and Third-Party Risk Management Program and Vendor Cybersecurity Diligence Checklist: A Practical Checklist. For the contract terms, see Cloud and SaaS Agreements: Service Levels, Data Rights, Security, and Exit.

Outputs of Step 6: the vendor inventory and tiering, diligence files, contract security exhibits, and the monitoring calendar.

Step 7: Train people and test the controls

Goal: proof that people know their part and that controls work. Owner: the program lead, with HR and internal audit. Time: ongoing, on an annual calendar.

7.1 Training

Part 500 requires cybersecurity awareness training at least annually, including social engineering; the Safeguards Rule requires training "updated as necessary to reflect risks identified by the risk assessment," 16 C.F.R. § 314.4(e)(1); HIPAA requires a security awareness and training program for the whole workforce. Build three layers:

  • Everyone: annual training plus periodic phishing simulations, with follow-up training for repeat clickers rather than public shaming.
  • High-risk roles: finance staff who can move money (business email compromise and payment-change fraud), help desk staff who can reset credentials (the target of most social-engineering intrusions), developers (secure coding and secrets management), and administrators.
  • Leaders and directors: a short annual briefing on the threat environment, the company's top risks, and their own roles during an incident. Part 500's requirement that the board have "sufficient understanding" makes this a compliance item, not a courtesy.

Keep completion records and simulation results. They are among the first items examiners request.

7.2 Technical testing

The Safeguards Rule requires either continuous monitoring or annual penetration testing plus vulnerability assessments at least every six months and after material changes. 16 C.F.R. § 314.4(d)(2). Part 500 requires annual penetration testing from inside and outside the network by a qualified party, automated scans with manual review of systems the scans miss, and timely remediation by risk. Class A companies must also commission independent audits of the program. Defense contractors face CMMC assessments, by a certified third-party assessor every three years for most Level 2 contracts, with annual affirmations in between.

Decision point: who tests? Use an independent outside firm for the annual penetration test, rotate firms every few years, and scope the test to the crown jewels identified in Step 1. A penetration test that excludes the systems that matter is worse than none, because it creates a false record of assurance.

7.3 Remediation tracking

Every finding goes into the risk register with an owner and a due date set by severity (for example, critical findings in days, high findings within a month, medium within a quarter). Track aging. Report overdue items to the steering committee, and overdue critical items to the board. A finding that cannot be fixed on time is either given a documented extension with compensating controls or formally accepted.

7.4 Tabletop exercises

Part 500 requires testing the incident response and business continuity plans at least annually, with senior officers and the highest-ranking executive participating. Even where not required, an annual tabletop is the cheapest insurance a company can buy. Good exercises force legal decisions, not just technical ones: Is this a "cybersecurity incident" under Part 500? A "notification event" under the Safeguards Rule? Material for SEC purposes? Who decides, and who is the backup if that person is unreachable? Do we pay? Write an after-action report with assigned improvements, and track them like audit findings.

Outputs of Step 7: training records, test reports, the remediation tracker, and tabletop after-action reports.

Step 8: Write and exercise the incident response plan, and map every clock

Goal: a plan people can execute under stress, with every legal deadline identified in advance. Owner: the program lead and legal. Time: four to eight weeks to write; exercised annually.

8.1 What the plan must contain

The Safeguards Rule lists seven required areas: goals; internal processes for responding; clear roles, responsibilities, and decision-making authority; internal and external communications and information sharing; remediation of identified weaknesses; documentation and reporting; and post-incident evaluation and revision. 16 C.F.R. § 314.4(h). Part 500 adds business continuity and disaster recovery planning, protected backups, and annual testing. HIPAA requires security incident procedures. NIST SP 800-61 Revision 3, issued in 2025 and aligned with CSF 2.0, is the standard technical reference.

8.2 The clock map

The plan should include a table like this one, customized to the company's regimes. Each clock has its own trigger, and the triggers are not the same.

Regime Trigger Deadline Recipient
NYDFS Part 500 Determination that a "cybersecurity incident" occurred (at the entity, an affiliate, or a vendor) 72 hours Superintendent, via portal
NYDFS Part 500 Extortion payment 24 hours; written justification within 30 days Superintendent
SEC Form 8-K Item 1.05 Determination that an incident is material (made without unreasonable delay) Four business days Public filing
FTC Safeguards Rule Discovery of a "notification event" involving 500 or more consumers As soon as possible, no later than 30 days FTC online form
Bank incident rule Determination of a "notification incident" 36 hours Primary federal regulator
NCUA Reasonable belief of a reportable cyber incident 72 hours NCUA
DFARS 252.204-7012 Discovery of a cyber incident affecting covered defense information 72 hours; preserve images 90 days DoD
Regulation S-P Unauthorized access to sensitive customer information No later than 30 days Affected individuals
HIPAA Discovery of a breach of unsecured PHI Without unreasonable delay, no later than 60 days; HHS at the same time if 500 or more Individuals, HHS, media
FTC Health Breach Notification Rule Discovery of a breach of unsecured PHR identifiable health information No later than 60 days; FTC at the same time if 500 or more Individuals, FTC, media
FCC (carriers) Reasonable determination of a breach Seven business days to FCC, FBI, and Secret Service; customers within 30 days unless harm is unlikely Agencies and customers
NAIC model law states Determination of a cybersecurity event 72 hours Insurance commissioner
CIRCIA (when CISA's final rule is effective) Reasonable belief of a covered cyber incident; ransom payment 72 hours; 24 hours CISA
State breach statutes Varies by state Varies (some fixed at 30 to 60 days) Residents, attorneys general
Contracts and insurance As drafted Often 24 to 72 hours Customers, insurer

Assign a named decision-maker (and a backup) for each trigger, and require that each determination be recorded with the date and time it was made and the facts it rested on. Regulators reconstruct timelines; a contemporaneous record of when the company knew what is the best defense to a lateness charge.

8.3 The materiality process for public companies

Decide in advance who sits on the disclosure committee for cyber incidents, what information the CISO must escalate and how quickly, and what factors the committee will weigh. The legal standard is the one in TSC Industries, Inc. v. Northway, Inc., 426 U.S. 438 (1976), and Basic Inc. v. Levinson, 485 U.S. 224 (1988): substantial likelihood that a reasonable investor would consider the information important, weighing probability and magnitude for developing events, with no bright-line test, Matrixx Initiatives, Inc. v. Siracusano, 563 U.S. 27 (2011). Prepare template 8-K language for Item 1.05 and Item 8.01, and a procedure for closing the trading window. A template materiality memo is in the companion toolkit, Cybersecurity Compliance Toolkit: Written Information Security Programs, Risk Assessments, and Incident Disclosure Memos.

8.4 The ransom protocol

Write the ransom decision process before it is needed: no payment without legal review, sanctions screening of the threat actor and any intermediary, insurer consent, law enforcement contact, and approval at a stated level (often the CEO with board notice). Sanctions liability under the International Emergency Economic Powers Act is strict, 50 U.S.C. § 1705, and OFAC's enforcement guidelines in 31 C.F.R. Part 501 credit prompt reporting and cooperation with law enforcement. Record every step, because NYDFS requires a written explanation of the diligence within 30 days of any payment.

8.5 Privilege and preservation

Pre-negotiate the engagement letters: outside counsel retains the forensic firm under a new statement of work for the purpose of legal advice, separate from any routine security services the firm already provides. Courts have refused protection where the arrangement was a relabeled business engagement, as in Premera and in In re Capital One Consumer Data Security Breach Litigation, 2020 WL 2731238 (E.D. Va. May 26, 2020). Plan for preservation: litigation holds, log retention, and forensic images (which DFARS requires for 90 days). For the response itself, see Responding to a Data Breach: The First Seventy-Two Hours and Data Breach and Incident Response Toolkit: From Detection to Notification.

Outputs of Step 8: the incident response plan, the clock map, the decision-maker roster, pre-approved engagement letters, template notices and 8-K language, and the ransom protocol.

Step 9: Report to the board, certify, and align disclosures

Goal: a written record that the board was informed and acted, and certifications that are true. Owner: the program lead, the general counsel, and the committee chair. Time: annual cycle, with quarterly updates.

9.1 The annual written report

The Safeguards Rule prescribes the content: the overall status of the program and the institution's compliance, and material matters including the risk assessment, risk management and control decisions, service provider arrangements, test results, security events and management's responses, and recommended changes. 16 C.F.R. § 314.4(i). Part 500's CISO report covers similar ground, plus material inadequacies and plans to fix them. A good report is short, comparative (this year against last year), and candid. Useful metrics include MFA coverage, mean time to patch critical vulnerabilities, open critical and high findings by age, phishing simulation results, incidents and near misses, vendor risk ratings, and the top ten risks from the register with their trend.

9.2 Minutes that show oversight

The record that won the Marriott and SolarWinds derivative cases was a record of regular reporting. Minutes should show that cyber was on the agenda, who presented, what written materials were provided, what directors asked, what follow-up they required, and what resources they approved. An executive session with the CISO, without management present, at least annually, is a good practice. For minute-taking mechanics, see Board Meeting and Minutes Checklist: A Practical Checklist.

9.3 Certifications

  • NYDFS: by April 15 each year, a certification of material compliance for the prior calendar year or a written acknowledgment of noncompliance identifying every deficiency and the remediation timeline, signed by the highest-ranking executive and the CISO. Keep the supporting documentation; the Department can ask for it. Do not certify compliance on the strength of a plan.
  • CMMC: annual affirmations of continuing compliance by a senior official. A false affirmation is a potential False Claims Act violation, 31 U.S.C. § 3729, and the Supreme Court's materiality test, Universal Health Services, Inc. v. United States ex rel. Escobar, 579 U.S. 176 (2016), is easier to satisfy when the government has made certification a condition of award. The DFARS clause implementing CMMC in contracts, 48 C.F.R. Part 204 and Part 252, began a phased rollout in November 2025, with third-party certification requirements expanding from November 2026.
  • Public companies: the CEO and CFO certify disclosure controls under Sarbanes-Oxley section 302, 15 U.S.C. § 7241, and management assesses internal control over financial reporting under section 404, 15 U.S.C. § 7262, which reaches IT general controls over financial systems. The disclosure controls rule is Exchange Act Rule 13a-15, 17 C.F.R. Part 240.

9.4 Drafting Item 106 from the facts

Draft the 10-K cyber disclosure by describing the program you built in Steps 1 through 8, in plain words, and nothing more. Check every sentence against a document: if the 10-K says the audit committee receives quarterly reports, the minutes must show four of them. Keep forward-looking descriptions modest. Coordinate the Item 106 text with risk factors so that no risk is described as hypothetical after it has occurred; that mismatch drove the SEC's cases against Pearson and Blackbaud and the Ninth Circuit's decision in In re Alphabet, Inc. Securities Litigation, 1 F.4th 687 (9th Cir. 2021). For the broader disclosure process, see Running a Public Company Disclosure Program: A Practical Guide.

Outputs of Step 9: the annual board report, minutes, certifications with supporting files, and the Item 106 drafting file.

Step 10: Prepare for examinations and investigations, and keep the evidence file current

Goal: the ability to answer a regulator's document request quickly, accurately, and consistently. Owner: legal and the program lead. Time: continuous.

10.1 How each regulator arrives

  • The FTC usually starts with a voluntary access letter or a civil investigative demand, often after a breach becomes public or after a Safeguards Rule notice is filed. Staff negotiate scope, take rolling productions, and may take testimony. The matter ends with a closing letter, a proposed administrative consent order, or a federal court complaint. Because AMG Capital Management, LLC v. FTC, 593 U.S. 67 (2021), took restitution off the table under Section 13(b), the negotiation is mostly about the order's terms and duration.
  • NYDFS examines licensees periodically, and its cybersecurity examiners follow up on incident notices and annual certifications. Investigations end in consent orders with penalties and remediation plans.
  • The SEC reaches public companies through the Division of Enforcement (voluntary requests, then subpoenas under a formal order, then a Wells notice) and reaches registered firms through the Division of Examinations, which reviews Regulation S-P and identity theft programs. After SEC v. Jarkesy, 603 U.S. 109 (2024), the SEC must bring securities fraud claims for civil penalties in federal court, before a jury, rather than in its own administrative forum.
  • HHS OCR opens a compliance review for every reported breach affecting 500 or more people and sends a data request letter. Resolution agreements include a payment and a multi-year corrective action plan. Civil money penalties are tiered by culpability under 42 U.S.C. § 1320d-5.
  • State attorneys general use civil investigative demands under their consumer protection statutes and frequently act as multistate coalitions after large breaches.
  • The Department of Justice investigates cyber-related false claims through civil investigative demands, 31 U.S.C. § 3733, often prompted by a whistleblower.

10.2 The evidence file: what your records must prove

Assemble and maintain one evidence file that maps to the requests regulators actually make:

  1. The regulatory applicability memo and the crosswalk (Step 1).
  2. Appointment documents, charters, and the organization chart (Step 2).
  3. The current and prior risk assessments and the risk register, with risk acceptances (Step 3).
  4. The WISP, the policies with approval dates, and the exception register (Steps 4 and 5).
  5. Control evidence: MFA coverage, encryption, access reviews, logging, patching metrics, backup restore tests (Step 5).
  6. The vendor inventory, diligence files, and contracts (Step 6).
  7. Training records, penetration tests, scans, audit reports, and the remediation tracker (Step 7).
  8. The incident response plan, the clock map, tabletop reports, and incident records with timestamped determinations (Step 8).
  9. Board reports, minutes, certifications, and disclosure files (Step 9).

Three properties make the file persuasive. Consistency: the policies, the board reports, and the public statements must say the same thing. Dates: every document should show when it was created and approved; regulators are suspicious of undated documents and alert to backdated ones. Candor: a record that shows problems found and fixed is more credible than a record that shows no problems.

10.3 Responding to a request

Issue a legal hold immediately, covering chat platforms and ticketing systems as well as email. Appoint one point of contact. Build the internal chronology before producing anything, so that the company's narrative is accurate and its witnesses are consistent. Produce what exists; do not create new documents and present them as if they existed earlier. Where gaps exist, show what the company has done since, because remediation and cooperation matter to penalty decisions under nearly every regime. For investigation mechanics generally, see Conducting an Internal Investigation: Scope, Privilege, and Reporting and the Regulatory Investigations Toolkit.

10.4 Negotiating an order

Most matters resolve by agreement, and the terms will govern the program for years. Focus on the definitions of covered information and covered incidents, the duration, the assessor's qualifications and scope, which affiliates are bound, whether any individual is named (the FTC named Drizly's CEO personally in 2023), reporting deadlines, and the process for modifying the order as technology changes. The alternative is litigation, which is possible but slow; LabMD won its appeal in 2018, years after it had stopped operating.

Strategy for each side

For the company building the program, the strategy is to make the program legible. Every requirement should trace to a control, every control to evidence, and every gap to a decision. Spend first where attacks succeed (identity, patching, backups, vendors), and document the reasons for the order of work.

For the regulator, the plaintiff, or the whistleblower, the strategy is to compare three things: what the law required, what the company said, and what the company's own documents show it did. The gaps between them are the case. Look for risk registers with stale items, penetration tests with recurring findings, MFA exceptions without approvals, vendor contracts without notice terms, board minutes without cyber reports, and public statements without substantiation. Insiders with knowledge of false security certifications to the government can bring qui tam actions under 31 U.S.C. § 3730; a court refused to dismiss one such case in United States ex rel. Markus v. Aerojet Rocketdyne Holdings, Inc., 381 F. Supp. 3d 1240 (E.D. Cal. 2019).

For directors, the strategy is to insist on written reporting, ask questions that are recorded, and fund what the program lead says is necessary or record why not. In re Caremark International Inc. Derivative Litigation, 698 A.2d 959 (Del. Ch. 1996), protects directors who make a good-faith effort to be informed; it does not protect directors who never asked.

For vendors on the receiving end of customers' diligence, the strategy is to standardize: maintain a current SOC 2 Type II report or ISO certification, a standard security exhibit, and a standard incident notice commitment you can actually meet. Vendors that cannot answer diligence questionnaires lose deals in regulated markets.

For employees and individuals, the law offers channels more than remedies. Security staff who see false statements to investors can report to the SEC's whistleblower program, 15 U.S.C. § 78u-6, which provides awards and anti-retaliation protection. Consumers can complain to the FTC and their attorney general, and California residents have the statutory damages claim described in the companion article.

Timeline and costs

A realistic first-year timeline

Months Workstream
0 to 1 Applicability memo; appoint the program lead and senior overseer; amend committee charter
1 to 3 Asset and data inventory; first written risk assessment; risk register
2 to 4 WISP and policy set approved; exception register created; public statements reconciled
2 to 9 Priority controls: MFA everywhere, endpoint detection, backups, patching cadence, logging, segmentation
3 to 6 Vendor inventory and tiering; contracts for critical vendors amended
4 to 6 Incident response plan, clock map, ransom protocol, pre-approved engagement letters
5 to 7 First tabletop exercise; first external penetration test; remediation tracker
6 to 12 Training cycle; second vulnerability assessment; vendor reassessments
12 Annual board report; certifications; Item 106 drafting; second-year risk assessment begins

Smaller institutions can compress this; complex or highly regulated ones will take longer, and a company already under investigation will be asked to accelerate.

What it costs

Costs depend on scope more than headcount, and quotes vary widely. As rough orientation for a mid-size company: a virtual CISO often costs a few thousand to a few tens of thousands of dollars per month; a scoped external penetration test often costs in the low tens of thousands of dollars; managed detection and response is priced per endpoint or user per month; a first SOC 2 Type II engagement with readiness work can reach six figures; and a CMMC Level 2 third-party assessment is a significant project for a small contractor, typically requiring months of preparation before the assessor arrives. Internal costs (staff time to write policies, run access reviews, and collect evidence) are often the largest and the least budgeted. Compare those numbers with the cost of an FTC order's assessments over twenty years, a seven-figure NYDFS penalty, or a single ransomware event, and the business case usually makes itself.

Common mistakes

  1. Buying tools before doing the risk assessment. Tools bought without a risk assessment protect whatever the salesperson demonstrated, and the assessment later reveals they cover the wrong systems.
  2. Adopting template policies wholesale. A policy the company does not follow is evidence of the gap between promise and practice.
  3. Scoping tests to avoid findings. Penetration tests that exclude critical systems create a misleading record and miss real risk.
  4. A program lead with a title and no authority. Regulators ask who could have stopped a risky decision. If the answer is no one, the appointment was cosmetic.
  5. Collecting SOC 2 reports without reading them. The exceptions and the user-entity controls are the point.
  6. An incomplete clock map. Part 500 counts incidents at affiliates and vendors; the Safeguards Rule imputes discovery to any employee; contracts may impose clocks shorter than any regulator's.
  7. Certifying on the strength of a plan. NYDFS penalizes inaccurate certifications. If remediation is not done, file the acknowledgment of noncompliance.
  8. Board reporting by slide deck. Without minutes recording the questions and decisions, the reporting does little for the directors later.
  9. Backups that have never been restored. Restoration is the test; until then, backups are a hope.
  10. Designing privilege during the breach. By then the forensic firm is already working under the wrong contract.

Worked example: a New York-licensed online lender builds its program in a year

The company. Cobalt Ridge Lending, Inc. makes online installment loans to consumers in thirty states. It has 140 employees, about $45 million in revenue (about $9 million of it from New York borrowers), and data on roughly 400,000 consumers: Social Security numbers, bank account details, income documents, and credit reports. Its loan platform runs on a public cloud; it uses a third-party servicing platform, a collections agency, a payment processor, and a bank-account verification service. Until 2025, the chief technology officer was the "acting" security lead.

Why it matters now. Cobalt Ridge obtained a New York lender license in 2025, which made it a covered entity under Part 500. In January 2026 it received notice of a NYDFS examination, and its new private equity investor demanded a security program as a condition of its next funding tranche.

Step 1 (January 2026): scope. Counsel's applicability memo identifies Part 500 (the New York license); the FTC Safeguards Rule (a nonbank lender is a financial institution within the FTC's jurisdiction, 15 U.S.C. § 6805); the CFPB's authority over unfair practices by lenders, 12 U.S.C. § 5531; the FTC's Red Flags and Disposal Rules, 16 C.F.R. Part 681 and 16 C.F.R. Part 682; Massachusetts' WISP regulation for its Massachusetts borrowers; and contract terms with its servicing platform and investors. Cobalt Ridge is not a Class A company (its New York revenue is under $20 million) and does not qualify for the limited exemption (more than 20 employees and more than $7.5 million in New York revenue). The decision: one program built to Part 500, crosswalked to the Safeguards Rule.

The certification decision (March 2026). The April 15, 2026 certification covered calendar year 2025, when Cobalt Ridge had no real program. Counsel advised filing an acknowledgment of noncompliance listing each deficient section and a remediation timeline rather than certifying material compliance. The CEO and the newly hired CISO signed it. That filing set the agenda for the examination and removed the risk of a false certification.

Steps 2 to 4 (February to April). Cobalt Ridge hires a full-time CISO who reports to the CEO, with a dotted line to the audit committee, whose charter is amended to cover cyber oversight. Directors attend a two-hour education session. The first written risk assessment ranks as top risks: cloud identity and access misconfiguration; credential-stuffing attacks against the borrower portal; developers' secrets committed to code repositories (the same failure behind the FTC's Drizly order); help desk social engineering; and a collections agency that receives borrower files by email. The WISP and fifteen policies are approved by the board in April, and the privacy policy's security language is rewritten to describe what the company actually does.

Step 5 (March to September). MFA goes on everything, with hardware security keys for cloud administrators, and borrowers are offered MFA on the portal. Secrets scanning blocks credentials from being committed. Cloud audit logs are centralized and monitored by a managed detection provider. Data older than the retention schedule is purged, after counsel reconciles the Safeguards Rule's two-year disposal default with state lending record-retention requirements.

Step 6 (April to July). The vendor inventory finds 61 vendors, nine of them critical. The collections agency agrees to a secure file-transfer channel, MFA, and 48-hour incident notice; the servicing platform provides its SOC 2 Type II report, whose exceptions the CISO reviews and documents.

Steps 7 and 8 (May to July). Cobalt Ridge writes its incident response plan and clock map, then runs a tabletop in July. The scenario: a credential-stuffing attack logs into 3,000 borrower accounts and views loan documents. The exercise surfaces a point the team had missed. Because the attack would require notices to state attorneys general, it would also be a "cybersecurity incident" under Part 500, which includes any event that requires notice to a government body, so the 72-hour NYDFS clock would run from that determination. And because more than 500 consumers' unencrypted customer information would have been acquired, the 30-day FTC notice would apply too. The after-action report assigns a decision-maker for each clock.

Step 9 and the examination (August to September). The NYDFS examiners receive the evidence file in an organized index within ten days of their request. Their report lists two findings (vendor reassessments not yet complete for two critical vendors, and an asset inventory that omitted several SaaS tools) with ninety days to remediate, and no enforcement referral. The CISO's written report goes to the board in September, with the findings, the plan, and the budget for year two.

What it cost. Roughly $1 million in the first year, about half for the CISO and a security engineer and the rest for managed detection, the penetration test, outside counsel, and consultants. The investor funded its tranche.

Frequently asked questions

Do we need a full-time CISO? Not necessarily. The Safeguards Rule allows the Qualified Individual to be employed by an affiliate or a service provider, with safeguards, and Part 500 allows a third-party CISO with oversight. What regulators require is a qualified person with authority and time. If the outsourced lead spends two hours a month on your program, that is the problem.

How often must we redo the risk assessment? Part 500 requires review and updating at least annually and when material changes occur. The Safeguards Rule requires periodic reassessment, and HIPAA expects the risk analysis to be kept current. Annual, plus triggered updates for acquisitions, major system changes, and significant incidents, satisfies all of them.

Can our managed IT provider be our Qualified Individual? It can, but it is rarely the best choice, because the person overseeing security would be evaluating the provider's own work. If you do it, designate a senior employee to direct and oversee the provider, require by contract that the provider maintain a program protecting you, and commission independent testing.

What if we cannot fix everything before the NYDFS certification deadline? File the acknowledgment of noncompliance. It must identify each section you did not materially comply with, describe the nature and extent of the noncompliance, and give a remediation timeline. Certifying compliance you do not have converts a remediation problem into an enforcement problem.

Does cyber insurance satisfy any of these requirements? No. Insurance is a way to transfer some financial risk, and it is a legitimate risk treatment in the risk register. It does not replace any required control, and insurers now condition coverage on many of the same controls the regulators require. See Placing and Tendering a D&O or Cyber Claim: A Practical Guide.

Does the board need a cybersecurity expert? No rule requires one. The SEC dropped a proposed requirement to disclose directors' cyber expertise, and Part 500 requires that the board have sufficient understanding to exercise oversight, which can come from education and outside advisers. What matters is that directors ask informed questions and that the minutes show it.

How long should we keep program records? HIPAA requires six years for required documentation. NYDFS expects supporting records for each certification to be available for examination for years afterward. FTC orders typically impose their own recordkeeping terms. Litigation holds override everything. A practical default is to keep program records for at least six years.

Is a SOC 2 report enough to prove compliance? It helps, but it is not designed for that. A SOC 2 report tests the controls the company chose to include against trust services criteria; it is not a legal compliance opinion, and its scope may exclude the systems a regulator cares about. Use it as evidence within the crosswalk, not instead of one.

Practical takeaways

  • Build the program in order: scope, people, risk assessment, documents, controls, vendors, testing, incident response, board reporting, and examination readiness.
  • Use one enterprise program built to the most prescriptive regime, and keep a crosswalk that ties every legal requirement to a control and its evidence.
  • Make risk decisions in writing, especially decisions to accept risk, and track every finding to closure.
  • Map every reporting clock before an incident, with a named decision-maker and timestamped determinations.
  • Certify only what is true, and use the noncompliance acknowledgment when it is not.
  • Give the board written reports and make sure the minutes show questions, follow-up, and resources.
  • Keep the evidence file current; the examination will be decided by documents.

This document is general information, not legal advice for any particular situation; the law changes, and the facts matter.

Related Documents

Companion documents in this series

Related Articles

Related Guides

Related Checklists

Related Toolkits