GDPR: technical and organizational measures in risk analysis

GDPR is the General Data Protection Regulation (EU) 2016/679 and establishes the obligations regarding the processing of personal data. In terms of financial crime and risk analysis, three of its articles apply directly: Article 25, which regulates data protection by design; Article 32, which lists security of processing; and Article 9, which classifies biometric data as a special category.

What does protection by design require?

Article 25 requires the data controller to implement appropriate technical and organizational measures both at the time of determining the means for processing and at the time of the processing itself. The use of aliases is cited as an example in the article, which states that the objective is to implement data protection principles, such as data minimisation, in an effective manner.

The assessment takes into account the state of the art, the cost of implementation, the nature, scope, context, and purposes of processing, as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons.

Which measures does Article 32 list?

After repeating the same assessment criteria, Article 32 explicitly lists four measures:

The fourth one is particularly striking: taking the measure is not enough, its effectiveness must also be regularly evaluated.

Is face matching a special category?

Yes. Article 9 prohibits, as a rule, the processing of biometric data for the purpose of uniquely identifying a natural person, and only permits it under specific conditions. Face matching and liveness checks in remote identity verification fall under this scope. Where data is processed, how long it is stored, and who accesses it is not merely a technical choice. The identity verification flow is on the customer onboarding page.

How does TruvaLI address this?

Access and logging. Access to personal data is subject to authorization, and who accessed it is recorded in the audit trail. Role and authorization definitions, approval policies, and documented delegation of authority are recorded separately. The audit log can be exported to a separate destination, meaning it can be streamed into the organization's own logging infrastructure. The regular evaluation required by Article 32(d) can be performed through these logs. Details are on the maker-checker, authorization, and audit trail page.

Deployment option is a measure. In an on-premise deployment, the software runs on the organization's own infrastructure, personal data remains within the organization's information systems, and keys are under the organization's control. Cloud and private cloud also remain as options. The measure to be taken at the time of determining the means of processing, as required by Article 25, also covers the choice of deployment model. Details are on the on-premise deployment page.

Biometric data is handled separately. Artifacts collected during the verification session are recorded separately: document image, data read from the chip, selfie, liveness video, and video call recording. When each is collected, which check it is used in, and how long it is stored can be managed individually. Details are on the video customer call page.

Data minimisation also applies on the rule side. The rule engine clearly shows which fields are used in which rule. When it is traceable which decision a field enters, it also becomes visible whether an unnecessary field is being processed. Details are on the rule and scenario engine page.

The EU framework on the laundering side is on the AMLA and EU regulations page, and its Turkish counterpart is on the KVKK page.

Source

General Data Protection Regulation (EU) 2016/679, Articles 9, 25, and 32.

This page does not constitute legal advice. The organization's own obligations should be evaluated by its own legal department.