ADR 10: External Log Source PII Behavior¶
Status¶
accepted
Context¶
We are evaluating external logging services and need to clarify how sensitive data is handled.
Per the SSG, PII is complex. A phone number alone is not PII. However with correlating info it can be consider PII.
In scope of this ADR¶
Log intake by a store that is external to our own applications, such as a cloud vendor or a JHA on-prem solution
Not in scope of this ADR¶
Logging to sources local to the application, such as the app database a log folder
Decision¶
We are taking the stance of avoiding PII correlation by filtering all PII by default. The data is removed entirely or obfuscated. Partial masking is not currently considered.
Fields to filter out of logs¶
- ExternalEntityIdentifier
- In our case, this is normally of type other with a guid value from Banno, however there is no expectation that it couldn’t be used with the other types. This field is present in a few GET calls.
- CoreCustomerId
- Could be PII depending on the data point used by the FI
- Financial account
- Token (SMS/email)
- Actual name or alias
- Physical address
Fields that do not need to be filtered out¶
- Service-level identifier such as guid or identify/NHILO
- Generated ID such as ZelleId
- IP Address
- IPs are tier 2. Can be classified as PII if related to other data. Since we are filtering other PII, IP addresses do not need to be filtered out.
Consequences¶
The absence of PII in our aggregated logs: - Allows for simpler access controls around the logging portal - Avoid additional restrictions on providing logs to developers - Simplifies log vendor engagement