Security and compliance

Periodically rechecking who still needs access to what, and removing the rest, which audits ask for and organisations routinely postpone.

Japan's core data-protection law, enforced by the Personal Information Protection Commission, so any business handling personal data belonging to people in Japan needs to meet its consent and security requirements.

A durable record of who did what and when, which is what turns a claim about how a system was used into evidence.

Permission given freely and specifically for a stated use of someone's data, one of several lawful grounds and not always the right one.

Data being taken out of an organisation without authorisation, whether by an attacker, a departing employee or a tool given too much access.

How an organisation decides who owns which data, who may use it and to what standard it is kept.

Controls that detect and block sensitive information leaving the organisation, increasingly pointed at what staff paste into AI tools.

The contract setting out what a vendor may do with personal data you send it, and usually a requirement before any real data moves.

A person exercising their right to see, correct or delete the data an organisation holds on them, within a deadline set by law.

India's data-protection law, whose provisions commence in stages, so a business handling the personal data of people in India needs to check which sections are already in force rather than assume the whole Act applies.

Keeping stored data unreadable without a key, so that copying the disk or the backup does not hand over the contents.

Protecting data while it moves between systems, which is what stops it being read by anything sitting on the network in between.

A vendor agreeing to stand behind you if generated output leads to a legal claim, offered mainly on business plans.

European legislation regulating AI by how risky its use is, placing the heaviest obligations on the highest-risk applications.

The European data protection regime, which shapes how personal data may be used and is often applied by companies well outside Europe.

An international certification for running an information security management system, often accepted alongside or instead of a SOC 2 report.

How encryption keys are created, stored, rotated and destroyed, which is where encryption usually succeeds or fails in practice.

Giving each person and system only the access it needs to do its job, which limits how far any single compromise reaches.

The conditions attached to using a model or its output, including whether commercial use is allowed and what may be trained on.

Requiring a second proof of identity beyond a password, and the single control that removes most account-takeover risk.

Removing a leaver's access across every system they touched, which is easy to do partially and hard to do completely.

Singapore's data-protection law, enforced by the Personal Data Protection Commission, which sets the baseline rules on consent, notification and data security for handling personal data of people in Singapore.

An authorised attempt to break into a system in order to find weaknesses first, usually reported on annually to customers.

Information that identifies a particular person, such as a name, email address or identity number, and the category most rules are written around.

China's national data-protection law, which governs how any business handling the personal data of people in China manages consent, cross-border transfers and security, whatever country the business itself is based in.

Information carrying legal obligations of its own, such as health or financial records, where the rules decide the tool rather than preference.

Granting access by job role rather than person by person, so joiners and leavers are handled by changing a role rather than remembering a list.

A standard for creating and removing user accounts automatically from your identity system, so access follows employment without manual steps.

The standard set of questions a buyer sends a vendor before approval, and often the slowest step in adopting a new tool.

Letting staff reach a tool with their existing work login, so access is granted and removed centrally rather than tool by tool.

An independent audit report on how a vendor handles security and availability, commonly requested before a tool is approved.

Another company your vendor passes your data to in order to deliver the service, which is why the published list is worth reading.

Exposure created by the vendors, models and libraries you depend on rather than by anything inside your own systems.

A written account of who might attack a system, how, and what it would cost you, used to decide which controls are worth the effort.

An approach that verifies every request rather than trusting anything because of where it came from, which suits work spread across many cloud services.