L68 · Regulation in financial services

Module 10: People, Governance, and Emerging Threats · ~20 min · Lesson 68 of 71

🎯 What you'll learn

• Why the rules that apply depend on what a company is
• What GLBA, NYDFS Part 500, PCI DSS, SOX and the SEC's cyber rules each require
• The notification clocks: 72 hours, 4 business days, 30 days
• What each rule means for an engineer's PRs, pipelines and logs

Not legal advice: this is an engineer's map. At a regulated firm, its compliance and legal teams own the interpretation. Dates were checked in late 2026.

🔥 Why this matters

In 2019 a journalist found that First American Financial's website exposed about 885 million title-insurance documents (bank account numbers, SSNs) to anyone who changed a number in the URL: a BOLA bug (L40). The SEC fined it $487,616 in 2021, partly because executives weren't told its security team had found the flaw months earlier. In 2023 it paid New York's regulator $1 million under Part 500. One missing check, two regulators, four years of consequences.

If you work at a bank, insurer, broker or payments company, or build software for one, these rules reach into your PRs, pipelines and logs. If you don't, this is still a useful map of what regulated customers and partners will ask of you.

1. What you are decides who regulates you

The rules depend on the kind of company, where it's licensed, and what data it touches. Most companies sit in several rows:

 IF THE COMPANY IS...            THEN LOOK AT...
 ──────────────────────────────────────────────────────────────
 a bank or credit union ───────▶ GLBA, via banking regulators
                                 (Interagency Guidelines)
 a non-bank lender, fintech, ──▶ GLBA, via the FTC:
 mortgage broker                 Safeguards Rule (16 CFR 314)
 an insurer ───────────────────▶ GLBA, via STATE insurance
                                 regulators; NAIC #668 laws
 licensed in New York ─────────▶ NYDFS Part 500
 (bank, insurer, lender...)
 handling payment card data ───▶ PCI DSS (a contract, not law)
 publicly traded ──────────────▶ SOX 404 + SEC cyber rules
 a broker-dealer or adviser ───▶ SEC Regulation S-P

If you work at one of these companies, its compliance team knows which rows apply.

2. GLBA and the FTC Safeguards Rule

The Gramm-Leach-Bliley Act (GLBA) of 1999 requires financial institutions to protect customers' nonpublic personal information (NPI): account numbers, balances, SSNs. Each regulator writes its own rules.

The FTC Safeguards Rule covers non-bank financial institutions such as lenders, mortgage brokers and many fintechs. Its 2021 amendments (in force by June 2023) require a named Qualified Individual, a written risk assessment, encryption in transit and at rest, MFA for anyone accessing any information system, secure development, change management, logging of user activity, a yearly penetration test plus scans every six months, an incident response plan, and a yearly board report.

A 2023 amendment, effective 13 May 2024, added breach reporting: notify the FTC within 30 days of discovering a notification event, meaning unauthorized acquisition of unencrypted customer information involving 500 or more consumers. Encrypted data doesn't count unless the key was taken too. State laws govern telling customers.

Insurers are left to state regulators. Many states have laws based on the NAIC Insurance Data Security Model Law (#668, 2017): a security program, board and vendor oversight, notice to the insurance commissioner within 72 hours, and an annual certification. Roughly half the states had adopted a version by the mid-2020s; check NAIC's adoption chart for the current list.

3. NYDFS 23 NYCRR Part 500

New York's Department of Financial Services (DFS) regulates anyone licensed under New York's banking, insurance or financial services laws, including out-of-state insurers licensed there. Its Part 500 (2017) is the most prescriptive cyber rule in US finance. Its second amendment (November 2023) phased in until November 2025:

 Nov 2023 ── second amendment adopted
 Dec 2023 ── new reporting rules: 72h incident notice,
             24h notice of a ransomware payment
 Apr 2024 ── new annual certification (CEO + CISO sign);
             governance, board reporting, encryption
 Nov 2024 ── MFA for remote access, privileged accounts,
             apps holding NPI; vuln mgmt, Class A EDR + logs
 Nov 2025 ── MFA for EVERY individual on ANY system;
             written asset inventory

• 72 hours: notify DFS within 72 hours of determining that a reportable cybersecurity incident occurred (500.17). A ransomware payment needs notice within 24 hours and a written justification within 30 days.
• CISO and certification: a CISO reports to the board; each 15 April the CEO and CISO certify compliance, or acknowledge gaps with a fix plan.
• MFA (500.12): since 1 November 2025, for any individual on any information system, unless the CISO approves an equivalent control in writing. For service accounts, see DFS's MFA FAQs.
• Audit trails (500.6): 5 years for reconstructing material financial transactions, 3 years for detecting and responding to incidents. Plus application security (500.8), asset inventory (500.13), and pen tests and scans (500.5).
• Class A (large) companies also need independent audits, EDR, centralized logging and PAM.

4. PCI DSS v4.0.1

The Payment Card Industry Data Security Standard (PCI DSS) isn't a law: the card brands set it and enforce it through contracts with acquiring banks. It covers systems that store, process or transmit card data, or can affect the cardholder data environment (CDE) (L13).

Version 4.0.1 (June 2024) is current; v4.0 retired at the end of 2024. Its future-dated requirements became mandatory on 31 March 2025. The ones engineers meet:

Best strategy: scope reduction. A provider's hosted page or iframe collects the card and returns a token, so your APIs never see a card number. (A January 2025 change removed 6.4.3 and 11.6.1 from SAQ A but added an eligibility condition about script attacks.)

5. SOX: IT general controls

The Sarbanes-Oxley Act (SOX) of 2002 makes public-company executives certify their reports (section 302) and assess internal control over financial reporting (section 404). SOX never mentions IT, but auditors test IT general controls (ITGCs) on systems feeding the financial statements: premium billing, reserves, commissions, Airflow jobs loading the general ledger.

ITGCs cover four areas: change management, access (periodic reviews of prod, AWS and DB access; leavers removed fast), segregation of duties (no one changes prod alone) and operations (batch jobs monitored, backups tested). Change management looks like this:

 ticket ───▶ PR #812 ─────────▶ CI ─────────▶ CD pipeline ──▶ prod
 FIN-4821    author: dev-a      tests, SAST    role deploys,
 (why)       approver: dev-b    passed         no human keys
   │           │                  │               │
   ▼           ▼                  ▼               ▼
 [authorized] [segregation]    [tested]      [who/what/when]
 ─────────── the evidence trail an auditor samples ────────────

For larger non-public insurers, the NAIC's Model Audit Rule imposes similar controls.

6. SEC cybersecurity disclosure rules

Adopted in July 2023, for public companies:

• Form 8-K Item 1.05: disclose a material cybersecurity incident within four business days of determining it's material, decided "without unreasonable delay" after discovery. Only the US Attorney General can authorize a delay. Incidents not (yet) judged material can go under Item 8.01.
• Form 10-K Item 106: yearly, describe cyber risk management and board oversight.

Industry groups petitioned in 2025 to rescind Item 1.05; as of mid-2026 it remained in force. Engineering logs feed the materiality call.

🧪 Worked example: one PR, five rulebooks

A made-up DAG copies policyholder records from MongoDB to S3. Assume every regime applies:

# dags/policy_export.py  (PR #934, author dev-c)
MONGO_URI = "mongodb://export:Spring2026!@mongo-prd:27017"  # 1
cols = ["policy_id", "name", "ssn", "dob", "card_number"]   # 2
s3.put_object(Bucket="gr-analytics-raw", Key=key,
              Body=to_csv(rows))                            # 3
log.info("exported %s", rows)                               # 4

And the map you'll actually use:

🛠 Try it (optional, ~5 min)

Read real Item 1.05 filings (public, read-only). In EDGAR full-text search (sec.gov/edgar/search), search "Item 1.05", filtered to form 8-K. In two filings, note when the incident was discovered, when it was judged material, and how much technical detail is given. Most say little: the rule doesn't require details that would hamper the response.

🧠 Key takeaways

• The rules depend on what the company is and where it's licensed; ask compliance.
• GLBA protects NPI; the FTC rule adds MFA, encryption and a 30-day report (500+ consumers).
• NYDFS Part 500: MFA for every person, asset inventory, yearly certification, 72-hour notice.
• PCI DSS is contractual; shrink scope with tokens so card numbers never reach your services.
• SOX makes the deploy pipeline evidence; SEC rules make logs a materiality input.

📖 Words to know

⏭ Next time

L69: privacy and data classification, and when to mask, tokenize or encrypt.

Teams that deploy twenty times a day sometimes assume SOX forbids it. It doesn't. SOX cares that every change to an in-scope system was authorized, tested, approved by someone other than the author, and deployed in a controlled way. Automation makes that easier to prove.

Populations and samples

Auditors don't read every PR. They ask for the population (every production change to the in-scope system in the period, generated by a system, not typed by you), then pick a sample, often 25 to 40 changes depending on frequency and the firm's method, and ask for evidence on each. One exception in the sample can become a finding.

 1. "Give me all prod deploys of billing-svc, Jan-Sep"
          │ system-generated list (pipeline + git)
          ▼
 2. Auditor checks the list is complete (vs deploy logs)
          ▼
 3. Picks 25 at random
          ▼
 4. For each: ticket? non-author approval? tests ran?
    deployed by pipeline? matches what's running?
          ▼
 5. Any gap = exception → maybe a deficiency

Where teams fail

• Admin bypass: an org admin merged without review "just this once". Rulesets with an empty bypass list prevent it (L67's worked example).
• Commits after approval: fixed by requiring approval of the latest push (L04, L57).
• Bot accounts that can merge or push to main: treat them as people for SoD.
• Emergency changes: allowed, if the process says so: deploy via the same pipeline, then get a documented after-the-fact approval within a set window.
• Drift: someone ran kubectl edit in prod. The running image digest no longer matches any approved build (L55's provenance helps here).

Worked example: finding your own exceptions first

Before the auditor does, list merged PRs on a repo you have access to and flag any without an approval from someone other than the author (made-up repo name):

gh pr list -R granite-ridge/billing-svc --state merged \
  --search "merged:2026-07-01..2026-09-30" --limit 500 \
  --json number,author,mergedBy,reviews \
  --jq '.[] | .author.login as $a |
        select([.reviews[] | select(.state=="APPROVED"
          and .author.login != $a)] | length == 0) |
        "#\(.number) by \($a), merged by \(.mergedBy.login)"'

#1187 by dev-a, merged by org-admin-1
#1203 by app/renovate, merged by dev-b

Two exceptions: an admin merge with no review, and a dependency bump nobody approved. Fix the ruleset, write up both with your compliance team, and you've turned a surprise finding into a known, remediated one. (Raise it through your own process; never edit or backdate evidence.)

🧠 Extra takeaways

• SOX doesn't ban continuous deployment; it wants authorized, tested, independently approved, controlled changes.
• Auditors test a system-generated population and a random sample; one gap can be a finding.
• Bypasses, bots, post-approval commits, emergency changes and drift are the usual exceptions.
• Query your own history before the audit, and fix the control, not the evidence.

L63 said legal joins early because of the clocks. Here's what that looks like for one made-up incident at Granite Ridge Insurance, assuming it's a New York-licensed, publicly traded insurer domiciled in a state with a #668-based law, that doesn't handle card data.

The incident

Stolen Airflow connection credentials let an attacker export 12,000 policyholder records (names, SSNs, policy numbers) from MongoDB, including New York residents.

Worked example: the clocks

 Mon 09:00  anomaly alert (L62)
 Mon 16:00  DETERMINED: incident occurred, NPI taken
   │
   ├─ +72h ──▶ Thu 16:00  NYDFS notice (Part 500)
   ├─ +72h ──▶ Thu 16:00  home-state insurance
   │                      commissioner (#668 law)
   ├─ state breach laws ─▶ consumers + some AGs,
   │                      "without unreasonable delay"
   │                      or 30-60 days in some states
 Wed 11:00  DETERMINED: material (disclosure committee)
   └─ +4 business days ─▶ Tue  Form 8-K Item 1.05

Count the 8-K days: Thursday, Friday, Monday, Tuesday. Weekends and federal holidays don't count.

Three details trip people up:

• Different triggers. NYDFS counts from determining an incident occurred; the SEC counts from determining it's material, which may be days later but must come without unreasonable delay.
• Not every clock applies. The FTC's 30-day rule doesn't cover an insurer, because GLBA leaves insurers to the states. If Granite Ridge took cards, PCI would add notice to its acquirer under card-brand rules. Contracts with partners often add their own 24 to 72 hours.
• Consumer notice is state by state, based on where the affected people live, not where the company is. Many #668-based laws also require notice to other states' commissioners when their residents are affected.

What engineers contribute

The lawyers own the filings, but every clock depends on facts only engineers can produce quickly:

Keep an incident timeline from the first minute (L63's scribe), state confidence ("at least 12,000; still checking backups"), and correct it in writing as facts change.

🧠 Extra takeaways

• One incident can start several clocks with different triggers: occurred vs material.
• NYDFS and #668 laws: 72 hours; SEC: 4 business days after materiality; FTC: 30 days, non-banks only.
• Consumer notice depends on where affected people live.
• Engineers supply the facts behind every clock; a precise, timestamped timeline is the key evidence.