The bank stores customer data, their personally identifiable data (PII) and is responsible for proper handling of such data with respect to privacy. This document aims to provide rules and guidelines for handling customer PII to prevent data leaks.
The requirements in this document are against the Production environment. It does not discuss how logs should be treated in other environments. The requirements were compiled from
Definition of PII
(Source provided by Lukas Civin )
While the internal primary identifiers of some objects, such as customerId, accountId, cardId, etc.. do uniquely identify a specific customer record in the system, they are not considered PII. Such identifiers only group the information together, but without the linked data (which are actual PII) they provide no identifiable information to the world outside of the system.
Requirements for PII data handling
Logging
No PII data should be exposed via Logs.
The logs pushed by the services should be designed to contain sufficient information to support debugging potential issues and monitor the traffic, but without the possibility of identifying a physical person from the logs.
Storage
Deletion of PII data must be supported. The data of once active customers can be stored up to 5 - 10 years for AML purposes. However, the data of prospect customers is subject to a much stricter period (days TBD Clarify max retention period for prospect customer data). The data of customers (also prospect) has to be deleted after the max retention period.
Kafka
There is no limitation on PII data being published to Kafka in any form, as long as:
There is either no manual access to Kafka, or the access is very limited and any such access is properly monitored and logged
The 3rd party services either do not connect to Kafka directly, or are exposed a topic which contains only the least amount of data the 3rd party service requires to function.
There is no limitation on internal backend services consuming any Kafka topic.
Database
There is no limitation on PII data being stored in the Databases of microservices, as long as:
There is either no manual access to DB, or the access is very limited and any such access is properly monitored and logged
No 3rd party service connects to a DB containing PIIs directly.
Exposing data to 3rd party services
PIIs can be exposed to 3rd party services, as long as:
the 3rd party service requires that specific PII data point to function properly
there are no redundant data in addition to what’s required sent/provided to the 3rd party service
Exposing data to specific roles within the bank
Some roles should have access to PII data (e.g. for fraud investigation or reporting). These roles will access the data either via:
Datalake - which will employ filtering on columns containing PII based on the role
Backoffice - the frontend application will connect to dedicated endpoints in the respective microservices which filter (or mask) the data available to the backoffice user based on their role.
