Case Study

Case Study: NYDFS Cybersecurity Regulation vs FTC Safeguards Rule Requirements

NYDFS vs FTC Safeguards Case Study

A detailed case study showing how a financial services firm met NYDFS cybersecurity regulation requirements while also aligning with FTC Safeguards Rule requirements, without fluff, without panic, and with clean documentation.

What this case study covers

Some compliance stories are simple: one regulation, one audit, one list of controls, done.

Financial services is not like that.

In the U.S., it is very common for one organization to be pulled under overlapping requirements. You might have state level expectations like 23 NYCRR 500 compliance and also federal level requirements like the GLBA Safeguards Rule, enforced through FTC Safeguards Rule requirements for many non bank financial institutions.

This case study shows what happened when one firm had to satisfy both tracks at the same time, while also responding to a real security event that tested whether their "compliance program" was a real program or just paper.

This is a composite case study based on common audit patterns, regulatory expectations, and incident response realities. Names and certain operational details are generalized so the focus stays on practical compliance decisions.

Background: The firm, the business model, and the compliance squeeze

Organization profile

HarborPoint Advisory Services is a mid sized financial services firm operating in multiple states. Their revenue comes from advisory services, retirement planning, and investment related operations. They handle sensitive client data such as:

They are not a giant bank. They are exactly the type of firm that often feels stuck between "big enterprise expectations" and "mid market resources."

Why both rules applied

HarborPoint had:

So they were not choosing a framework for fun. They had legal expectations coming from more than one direction.

The internal reality before the case begins

HarborPoint had a security program, but it was uneven:

They also had a common problem: different teams treated NYDFS and FTC as two separate projects instead of one unified program.

That became the first thing that had to change.

The trigger: Two audits land in the same quarter

Audit 1: NYDFS style control evidence request

HarborPoint received an NYDFS oriented evidence request that asked for items like:

Their compliance director described it simply: "They are not asking if we have a policy. They are asking if we run the policy."

That is a key difference. NYDFS oriented scrutiny tends to focus on whether controls are operational and documented, not just written down.

Audit 2: FTC Safeguards driven assessment

At nearly the same time, the firm received an assessment aligned to FTC Safeguards Rule requirements, focused on:

The biggest issue was timing. HarborPoint needed to respond to both without doubling work or creating inconsistent narratives.

Step 1: Stop treating them as two different security programs

The first leadership meeting

HarborPoint's COO wanted to assign one team to NYDFS and one team to FTC. The CISO pushed back.

He explained: if we split it, we will produce two sets of documents, two sets of terminology, and two different stories. That creates risk.

Instead, they created a single "control mapping" workstream with one goal: build one set of financial institution cybersecurity controls that satisfy both obligations, then produce evidence once and reuse it.

The mapping approach they used

They created a simple matrix with:

This mapping exercise became their compliance backbone. It did not magically fix controls, but it stopped the chaos and created a single source of truth.

The hidden benefit

Once they did the mapping, they discovered something important: most control goals were the same. The differences were in documentation style, specificity, and audit evidence.

That meant the right plan was not "build twice." It was "build once, document well."

Step 2: The risk assessment becomes the anchor document

Why the risk assessment mattered

Both NYDFS and FTC oriented reviews tend to start with risk: did you identify risks realistically, and did you implement safeguards based on that assessment?

HarborPoint had a risk assessment, but it was too high level. It was full of statements like "phishing risk is high" without connecting that to specific assets, data flows, and compensating controls.

The firm decided to rebuild the risk assessment as a working document that could survive scrutiny.

What changed in the new risk assessment

They made five practical changes:

  1. They listed the systems that store or process customer data, not just categories
  2. They mapped data flows between systems and vendors
  3. They tied each major risk to a control set and an evidence artifact
  4. They identified residual risk and the decision owner who accepted it
  5. They set a review schedule that was realistic and enforceable

This is where many firms fail. They create risk assessments as a one time exercise. Regulators look for a living program.

Step 3: The identity problem that both audits exposed

The ugly discovery

During evidence collection, HarborPoint found:

This was not just a technical issue. It was a governance issue, and it impacted both 23 NYCRR 500 compliance and FTC Safeguards Rule requirements expectations.

The fix: "Minimum access" in plain English

They implemented a strict rule: no shared accounts. Every login must map to a person. Every privileged role must have an owner. Every admin action must be logged.

Then they implemented the practical steps:

The important part was not just making the change. It was documenting it in a way auditors could verify quickly.

Step 4: Logging and monitoring becomes the proving ground

Why monitoring became central

When auditors ask "How do you know your safeguards work," the answer is rarely "because we bought a tool."

The answer needs evidence: logs, alerts, ticket records, investigations, and corrective actions.

HarborPoint had logs, but they were fragmented across endpoint tooling, firewall logs, email security logs, and a cloud admin console.

They had no unified story.

What they built

They implemented a simple monitoring model:

They also wrote a one page monitoring policy in normal language: what is monitored, what is reviewed, who reviews it, and what counts as escalation.

This created evidence that satisfied both audit tracks without building two different systems.

Step 5: Vendor management becomes non negotiable

The vendor reality in financial services

HarborPoint relied on service providers for:

Auditors focused on one question: if a vendor fails, can you show you assessed them, required safeguards, and reviewed their performance?

Their vendor program existed, but it was inconsistent. Some vendors had full documentation. Others had almost nothing beyond a contract.

What they changed

They created a vendor tiering model:

For Tier 1, they required:

They also created a vendor exception process: if a vendor could not meet a requirement, the business had to accept the risk in writing, with a remediation plan.

This was uncomfortable at first because business teams hate friction. But it created a defensible record.

Step 6: Incident response is tested by a real event

The timing could not have been worse

Halfway through audit evidence collection, HarborPoint experienced a security event: a credential stuffing attempt targeted their client portal login.

It did not become a breach, but it created operational stress:

This was the moment where auditors and regulators would see whether the firm's controls were real.

What happened in the first hours

HarborPoint followed a clean response flow:

  1. Identify: Monitoring flagged abnormal login patterns
  2. Contain: They enabled stricter rate limiting and additional bot protections
  3. Validate: They checked for successful account takeovers
  4. Recover: They reset affected accounts and restored normal user access
  5. Document: They recorded timelines, decisions, and actions

The key was documentation. They created an incident record with:

That incident ticket later became one of their strongest audit artifacts because it showed the program in motion.

Step 7: The compliance documentation that made audits easier

The "evidence pack" concept

Instead of scrambling each time auditors asked a question, HarborPoint created an "evidence pack" organized by control domain.

Each section contained:

For example, the access control section included: policy, MFA enforcement proof, access review logs, and one sample approval chain.

The vendor management section included: vendor tier list, questionnaires, contract clauses, and recent vendor review notes.

This prevented the most common problem in compliance: the controls exist, but evidence is scattered and hard to produce.

Step 8: Reconciling NYDFS and FTC language differences

Where firms get tripped up

NYDFS style reviews often emphasize governance and formal program structure. FTC GLBA aligned reviews often emphasize risk assessment, safeguards, and service provider oversight.

A firm can accidentally write two narratives: one sounds like a board governance story, the other sounds like an IT checklist.

HarborPoint unified language with a simple rule: describe one program, one set of safeguards, one governance model, and map it to both requirements.

They kept descriptions factual and plain:

This reduced confusion and made it easier to answer questions consistently.

Step 9: The remediation plan that auditors actually respected

No one believes "we will improve"

Auditors see vague promises all day.

HarborPoint created a remediation plan with:

They also tracked "risk accepted" items separately. When something could not be fixed immediately, they documented: why, what mitigation existed, who accepted it, and when it would be revisited.

That documentation matters. It shows governance.

Results: How the firm passed both audits without running two programs

The NYDFS oriented outcome

The NYDFS style review went smoothly because:

The FTC GLBA aligned outcome

The FTC Safeguards oriented assessment was satisfied because:

The firm did not become perfect overnight. But they became defensible, and in compliance, defensible matters.

What went wrong and what they learned

Lesson 1: Separate projects create compliance risk

When teams split NYDFS and FTC into two workstreams, they create contradictions. A unified program avoids that.

Lesson 2: Evidence beats intention

Auditors do not grade your intent. They grade what you can prove.

Lesson 3: Vendor risk is business risk

If a vendor touches customer data, your compliance exposure increases unless you can show oversight.

Lesson 4: A real incident is the ultimate test

A small event handled well can become your strongest compliance evidence.

Practical template you can apply

If you need to satisfy both requirements, focus on these core domains

Build one program. Produce one evidence pack. Map once.

Closing

The most realistic compliance strategy for overlapping financial cybersecurity requirements is not to build two security programs. It is to build one mature program with strong documentation and operational proof.

This case study shows that NYDFS cybersecurity regulation and FTC Safeguards Rule requirements can be met through a single, well structured program when the focus stays on controls, evidence, and disciplined documentation.

← Back to All Case Studies