Under amended SEC Regulation S-P, sensitive customer information is any component of customer information, alone or combined with other data, whose compromise could create a reasonably likely risk of substantial harm or inconvenience to the individual. The rule gives examples such as Social Security numbers, biometric records, and account identifiers paired with authenticating details.
This is general information, not legal advice.
The definition
The rule text defines it in paragraph (d)(9). The test is risk based: could compromise create a reasonably likely risk of substantial harm or inconvenience to the person the data identifies? The examples illustrate that test and are not a closed list.
Examples from the text
| Category | Examples in the rule |
|---|---|
| Authenticating identifiers | Social Security number, driver's license or government ID number, alien registration number, passport number, employer or taxpayer identification number |
| Biometrics | A biometric record |
| Electronic identifiers | A unique electronic identification number, address or routing code |
| Access devices | Telecommunication identifying information or an access device as defined in federal law |
| Account data plus authenticators | Account number, name or online user name combined with items such as an access code, card expiration date, partial Social Security number, security code, security question and answer, date of birth, place of birth or mother's maiden name |
A name on its own is not in the list. A name or account number combined with an item that could be used to gain access to the account is.
Why the definition matters to engineers
The notification duty turns on it. The institution must notify affected individuals whose sensitive customer information was or is reasonably likely to have been accessed or used without authorization, subject to the harm analysis. The more precisely you know where those fields live, the faster scoping goes.
Turn the definition into field tags
- List every table, file store and message queue that holds customer information.
- Tag fields as sensitive or not using the categories above.
- Tag combinations too, since the risk can come from a pairing such as account number plus date of birth.
- Record which systems copy the data, including logs, analytics exports and test data.
- Review tags when schemas change.
Logs deserve attention. Debug output that prints an account number next to a birth date can create sensitive data in a place nobody classified.
Related but different terms
Customer information, in the rule, means records containing nonpublic personal information about a customer, including information a covered institution receives from another financial institution. Sensitive customer information is the narrower subset that triggers individual notice.
Mistakes to avoid
Common errors are tagging only the production database and forgetting logs, backups and analytics copies; treating the list of examples as closed; and ignoring combinations such as an account number with a security answer. Another is classifying once and never again, so new fields added by developers go untagged. Add a review step to schema changes and scan logs for patterns that look like the examples above.
Quick check
Is a customer's name alone sensitive customer information?
The rule's examples pair a name or account identifier with authenticating information. The overall test is whether compromise could create a reasonably likely risk of substantial harm or inconvenience.
Is the list of examples exhaustive?
No. The examples follow the word "include" and illustrate the general test.
Sources
- SEC adopting release 34-100155, rule text for paragraph (d)(9)
- SEC fact sheet, Final Rules: Enhancements to Regulation S-P
Last reviewed: 19 October 2026.
