Updated September 28, 2026
A firm can have a cybersecurity policy, a security provider and a folder of assessment reports—and still struggle to answer a regulator’s basic question: Can you demonstrate that your controls work?
Preparing for cybersecurity compliance requires more than buying technology or updating policy language. It means connecting legal obligations to operational controls, accountable people and reliable evidence.
For firms revisiting their 2023 planning, the regulatory landscape has changed. These five practices provide a current roadmap, particularly for U.S. financial-services businesses. Confirm applicability with qualified counsel; requirements depend on your activities, registrations, jurisdictions and exemptions.
1. Determine What Applies Before Building Your Compliance Plan
Start with your legal entities and business activities—not a generic compliance checklist. Similar businesses can have different obligations because they operate under different registrations or licenses.
Separate enacted requirements from outdated proposals
The SEC withdrew its proposed cybersecurity risk-management rules for investment advisers and funds in 2025. Do not treat that proposal’s reporting framework as an enacted requirement. Other requirements, however, have reached their compliance dates:
- SEC Regulation S-P: Amendments address incident response, customer notification, service-provider oversight and recordkeeping for covered institutions. The compliance dates were December 3, 2025, for larger entities and June 3, 2026, for smaller entities. Both have passed.
- New York DFS Part 500: Covered entities must assess applicable requirements and exemptions. The implementation schedule reached expanded multifactor authentication and asset-inventory requirements on November 1, 2025, subject to applicable exceptions and exemptions.
- FTC Safeguards Rule: Financial institutions within FTC jurisdiction need a written information-security program. The limited exemptions for institutions maintaining information on fewer than 5,000 consumers are not a blanket exemption.
- SEC public-company rules: Covered public reporting companies have separate cybersecurity disclosure obligations, distinct from Regulation S-P.
Create an applicability register recording each entity, requirement, applicability rationale, exemption, deadline, owner and required evidence. Track contractual and insurance conditions separately from legal requirements.
Practical example: An organization with multiple regulated subsidiaries should assess each entity separately rather than assume one groupwide determination covers everything.
Deliverable: A counsel-reviewed register with accountable owners and a review schedule. An incomplete register makes even a well-executed program unreliable.
2. Prioritize Controls Around Actual Risk
A framework provides structure; it does not determine your legal obligations. NIST’s Cybersecurity Framework 2.0 organizational profiles offer a useful way to compare current capabilities with target outcomes and prioritize gaps. The framework is voluntary, not a compliance certification.
Map critical services, then verify protection
Inventory systems, cloud applications, sensitive data and providers. For each critical service, identify its owner, privileged users, data locations and recovery dependencies. Then prioritize:
- Access security: Verify MFA coverage, particularly for administrators and remote access. Favor phishing-resistant MFA, with workable enrollment and recovery procedures.
- Least privilege: Remove unnecessary access and review permissions when responsibilities change or people leave.
- Vulnerability management: Prioritize weaknesses using exposure, exploitation risk and business impact.
- Detection: Collect useful logs and assign responsibility for investigating alerts, including outside business hours.
- Recovery: Maintain protected backups and test restoration. CISA recommends offline, encrypted backups and regular recovery testing.
Train employees to recognize suspicious requests and report them through a clear channel. Technical protection and human response should reinforce each other.
Practical example: “MFA purchased” is not completion. Required accounts enrolled, exceptions reviewed and account recovery tested is a defensible completion standard.
Tradeoff: Security changes can disrupt operations. Pilot where appropriate, but give exceptions an owner, compensating protection and expiration date. Internal risk acceptance cannot waive a mandatory requirement.
Deliverable: A prioritized remediation plan with owners, deadlines and verification criteria.
3. Treat Vendor Oversight as an Ongoing Responsibility
Outsourcing technology does not eliminate your firm’s oversight responsibilities. Concentrate attention on providers that hold sensitive information, administer systems or support critical operations.
NYDFS’s third-party risk guidance emphasizes risk-based due diligence, contractual protections and ongoing monitoring. An onboarding questionnaire alone is insufficient.
Review assurance-report scope, exceptions and controls your firm must operate. Evaluate subcontractors, incident cooperation, recovery capabilities and exit options. For AI services, assess permitted data use, retention and whether firm information may train models.
Make incident coordination explicit
Under amended Regulation S-P, covered institutions’ policies and procedures must be reasonably designed to ensure providers notify them as soon as possible, but no later than 72 hours after awareness of a breach resulting in unauthorized access to a customer information system maintained by the provider.
The final rule does not impose the proposal’s specific written-contract requirement for that provision. Nevertheless, documenting notification contacts, evidence preservation and investigation cooperation in contracts can strengthen execution.
Tradeoff: Large providers may reject bespoke terms. Document gaps and consider limiting data exposure, narrowing access or choosing an alternative.
Deliverable: A risk-tiered vendor inventory, current review records and tested escalation contacts.
4. Build Incident Response Around Distinct Reporting Triggers
A policy that says “report breaches within 72 hours” is too blunt. Different obligations have different triggers, recipients and clocks.
- Regulation S-P customer notification: When required, notify affected individuals as soon as practicable, no later than 30 days after awareness that unauthorized access to or use of customer information occurred or was reasonably likely. The rule includes a reasonable-investigation exception tied to whether sensitive customer information has been, or is reasonably likely to be, used in a manner causing substantial harm or inconvenience.
- NYDFS notification: Notify DFS as promptly as possible, no later than 72 hours after determining that a qualifying cybersecurity incident occurred. Separate extortion-payment requirements include notice within 24 hours and an explanation within 30 days of payment under Part 500.
- FTC notification: Notify the FTC as soon as possible, no later than 30 days after discovery of a notification event involving unauthorized acquisition of at least 500 consumers’ unencrypted information. Compromised encryption keys and the rule’s presumption concerning unauthorized access matter.
- SEC public-company disclosure: Domestic registrants generally file Form 8-K Item 1.05 within four business days after determining materiality—not discovery. That determination must occur without unreasonable delay; limited disclosure-delay provisions exist.
These summaries are not a complete reporting inventory. State breach laws and contractual obligations may also apply.
Practical example: Exercise a compromised-email scenario involving suspected customer-data theft. Bring together leadership, IT, legal, compliance and relevant providers. Record when facts became known, who authorized containment and who evaluated each notification obligation.
Tradeoff: Waiting for forensic certainty can conflict with deadlines. Design the process for timely decisions based on available facts, followed by documented updates.
Deliverable: A tested response plan, reporting matrix, contact list and exercise-remediation log.
5. Make Evidence and Leadership Review Routine
A policy describes intended behavior. Evidence shows what happened. For each material control, retain its requirement, owner, configuration or review record, test result, exception and remediation deadline.
For example, an access-review policy should connect to an actual account list, documented decisions and tickets showing unnecessary access was removed.
Give leadership decision-useful measures: overdue high-risk findings, unprotected accounts, critical-provider issues, failed restoration tests and expired exceptions. Counting completed documents is not the same as measuring protection.
For NYDFS-covered entities subject to the requirement, the annual submission due April 15 is either a certification of material compliance for the prior calendar year or an acknowledgment of noncompliance. Supporting records must be retained for five years. Do not turn a known gap into an unsupported certification.
Tradeoff: Collecting everything creates noise and cost. Preserve evidence that demonstrates scope, operation and outcomes while satisfying retention requirements.
Deliverable: A maintained evidence index and leadership-reviewed improvement plan.
Cybersecurity Compliance Readiness Checklist
Use this as an operational work plan—not a legal safe harbor or an extension of an expired deadline.
- Confirm covered entities, applicable rules and exemptions.
- Separate enacted requirements from proposals and voluntary guidance.
- Assign executive accountability and control owners.
- Inventory critical systems, sensitive data and providers.
- Verify MFA coverage and remove unnecessary access.
- Prioritize vulnerabilities and test critical-service restoration.
- Review provider notification arrangements and escalation contacts.
- Document separate customer, regulator and investor reporting decisions.
- Exercise incident response and track corrective actions.
- Maintain control evidence and escalate unresolved requirements.
- Review progress with leadership and reassess after significant changes.
Build a Program You Can Demonstrate
Effective compliance preparation answers four questions: What applies? Who owns it? Does it work? Can we demonstrate that?
Start with a leadership review of your applicability register and highest-risk gaps. Then test a critical control and an incident-reporting scenario. The objective is not a larger policy library. It is a security program that protects the business, meets applicable obligations and produces evidence when it matters.