top of page
Theat categories


In general

Not being compliant with legislation, regulations, and corporate policies.


  • Can lead to fines (when violating legislation, or not adhering to the communicated corporate policies)

  • Can lead to loss of image, credibility, etc.

Impacted by

  • Security officer/legal audit/… : a person responsible for the system's compliance (+)

  • Tampering with the policy data store: when the policy database is not tamper-proof, attackers can alter the access control policies and user consents of the system (-)



No distinction is made between the different DFD elements, as compliance generally applies to the system as a whole.

LINDUN non-compliance threat tree

Tree in general

A system is compliant when it adheres to its communicated corporate policies, to all (data protection) legislation, and to the user's consents.

The tree only aims at identifying compliance issues (related to privacy) from a high-level perspective. To ensure full compliance, we advice the assistance of a legal expert.

Leaf nodes explanation

Legal compliance is a very complicated domain and will generally require the assistance of a legal expert. Related work exists that summarizes the most common principles in data protection legislation.
Anton, Earp, and Reese [1] summarize 5 privacy protection goals as notice/awareness, choice/consent, access/participation, integrity/security, enforcement/redress.
Guarda and Zannone present 9 privacy principles [2]: fair and lawful processing, consent, purpose specification, minimality, minimal disclosure, information quality, data subject control, sensitivity, and information security.

Privacy policies can have several origins. They can be imposed by law (like data protection legislation), but also each company has its own corporate policies (which are also communicated with the users) to which the system should adhere. On top of that, the users themselves can also be involved in the privacy rules by means of consents. Users should be able to decide what happens with their data and who has access to their information. They can elicit their rules in the form of user consents. These consents can either be to allow certain actions to their personal information. Examples are: allow data to be used for research, or allow data to be communicated with a third party, or even allow person X to access (and/or update) my personal data). A consent can also restrict access, when a user decides he does not want a certain person or party to access his personal information (e.g. prohibit your neighbor who works in a hospital to access your medical records). Consents and privacy policies in general can, and should, be integrated into the system's access control policies as much as possible.

Attacker tampering with privacy policies and makes consents inconsistent (NC_1)

When the privacy policies and consents are integrated in the access control system, it is important that they are stored in a correct and consistent fashion. Clearly, when an attacker can tamper with the policies (NC_1), the attacker can alter or remove the policies (and consents) and the system can no longer ensure compliance. This can happen when the database that stores the policies is susceptible to tampering threats (T_DS of STRIDE).

Incorrect or insufficient privacy policies (NC_2)

To "automate" compliance, these policies need to be enforced in the system. When the privacy policies are incorrectly or insufficiently implemented (NC_2), the system will not be compliant. When insufficient policy management (NC_3) is provided, the system will not be compliant to the user consent requirements. Insufficient policy management exists when the system does not provide (user-friendly) support to the user to create or update user consents, or, when the created user consents are not correctly enforced in the system. This insufficient policy management can be both accidental and intentional.

Finally, also related to the system's corporate policies is the threat related to notice (NC_4). Clear, transparent notice of the applied policies should be provided to all users to inform them about the data that will be collected, stored, and processed [3].

Note that these threats are only related to privacy policies. Data protection compliance spans a much broad range of threats (most of which also occur in other LINDDUN threat trees). Those threats are mainly related to storage and overall management of data that is not compliant with legislation or the specified corporate policies. They include (but are not limited to): insufficient minimization (collecting and storing too much information with respect to its purpose), storing data too long (data retention), storing sensitive data without the necessary precautions (anonymizing, encrypting,...), not providing the data subjects with access to their data, not respecting the 'right to be forgotten', ... To guarantee full legal compliance, we advice the assistance of a legal expert.

[1] Anton, A.I.; Earp, J.B.; Reese, A., 2002, "Analyzing Website privacy requirements using a privacy goal taxonomy," Requirements Engineering, 2002. Proceedings. IEEE Joint International Conference on , pp.23,31

[2] Paolo Guarda and Nicola Zannone. 2009. "Towards the development of privacy-aware systems".Inf. Softw. Technol. 51, 2 (February 2009),pp. 337-350.

[3] Tools like Privacy Bird have already emerged that inform users about how information they provide to websites could be used. These tools interpret the website's privacy policies and translate them to information that is easier to grasp (as privacy policies are hardly ever read by users because they tend to be very extensive and hard to comprehend). Ideally however, each system provides its own easy to grasp notice.

Non-compliance threat tree
bottom of page