Compliance terms, defined for engineers.

Audit evidence is the proof that a control actually operated: the access review that was performed, the log that recorded an event, the approval on a change. An auditor does not take your word that a control works; they sample evidence that it did, across a period.

Audit logging is recording security-relevant events, such as logins, privilege changes, and access to sensitive data, so they can be monitored and later investigated. You cannot detect or reconstruct what was never recorded, which is why frameworks treat logging as a foundational control.

Compliance as code is the practice of expressing and checking compliance obligations where the system actually lives, in the repository and the pipeline, rather than only in a policy document reviewed once a year. It borrows the move that worked for testing and infrastructure: take something manual and periodic and make it defined and continuous.

A control is a specific measure a framework expects you to have in place to manage a risk, for example restricting access to authorized users, encrypting data in transit, or logging security events. Frameworks are essentially structured lists of controls plus the evidence that they operate.

Data minimisation, a GDPR principle (Art. 5(1)(c)), is the rule that you should only collect, use, or otherwise process the personal data a purpose actually needs, and no more. Capturing extra data 'just in case' is the exact thing it forbids.

Data retention is how long you keep data before deleting it. Under GDPR's storage-limitation principle (Art. 5(1)(e)), personal data should not be kept in an identifiable form for longer than the purpose needs, so most personal-data stores need a defined retention period (with narrow exceptions, such as archiving or research, under safeguards).

Encryption in transit protects data while it moves across a network, typically with TLS, so it cannot be read or tampered with between systems. It is distinct from encryption at rest, which protects stored data.

Human oversight, a requirement of the EU AI Act (Art. 14) for high-risk AI systems, is the expectation that a person can effectively oversee the system, including monitoring it, interpreting its output, and being able to disregard, override, or reverse that output or stop the system, proportionate to the risk and context.

Least privilege is the principle that a user, role, or process should have only the access it needs to do its job, and no more. Narrow access limits the damage of a mistake or a compromise, and it is what an auditor checks when they sample your access controls.

Logical access control is restricting who and what can reach a system or data to those authorized to have it, the digital equivalent of locks and keys. It is central to SOC 2's logical-access criteria, CC6.1 in particular, and appears across every security framework.

Personal data is any information relating to an identified or identifiable natural person, under GDPR. It is what is loosely called 'personally identifiable information' (PII), though the GDPR term is broader: a name or email obviously, but also an IP address, a device id, or anything that can be linked back to an individual.

Secrets management is how an application handles credentials, API keys, and private keys: where they are stored, how they are accessed, and how they are rotated. The goal is that a secret never lives in source code, a log, or any place it can leak.

Shifting compliance left means moving the compliance check earlier in the development lifecycle, to the moment a change is made, instead of discovering issues later in an audit. The term borrows from shift-left security and testing: the earlier a problem is found, the cheaper it is to fix.

The Trust Services Criteria are the set of criteria a SOC 2 examination is judged against, defined by the AICPA. They cover security (the common criteria, CC), and optionally availability, processing integrity, confidentiality, and privacy.