This organization

• EU AI Act: 0 of 1 in-force obligations evidenced
• GDPR: 0 of 17 in-force obligations evidenced
• ISO/IEC 42001: 0 of 70 requirements evidenced
• ISO/IEC 27001: 0 of 123 requirements evidenced
• SOC 2: 0 of 61 requirements evidenced
• Texas TRAIGA: 0 of 5 in-force obligations evidenced
• EU Cyber Resilience Act: 0 of 2 in-force obligations evidenced, 6 not yet in force
• Utah AI disclosure law (Code 13-77): 0 of 4 in-force obligations evidenced

A count of applicable obligations and requirements that are evidenced. Not a compliance score, a certification, or legal advice. Laws not yet in force are shown separately.

Role: PROVIDER · Risk tier: LIMITED

• Article 50: Transparency obligations for providers and deployers of certain AI systems [Regulation (EU) 2024/1689 (Artificial Intelligence Act); Article 50; ELI http://data.europa.eu/eli/reg/2024/1689/oj; CELEX 32024R1689]

Source: Regulation (EU) 2024/1689, © European Union, https://eur-lex.europa.eu, 1998–2024. Only EU legislation published in the electronic edition of the Official Journal of the European Union is deemed authentic.

• Article 5: Principles of processing (lawfulness, fairness, minimisation, accuracy…) [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 5; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Process personal data against the core data-protection principles and be able to show it: lawfulness, fairness and transparency; a specified and legitimate purpose; collecting no more than is needed; keeping it accurate and up to date; retaining it no longer than necessary; and holding it securely. The accountability principle means the controller must be able to demonstrate this, not merely assert it.

  • A data-protection policy that states the principles and how they are applied in practice
  • A retention schedule setting how long each category of data is kept and when it is deleted
  • A record showing each processing purpose and the minimisation decision behind the data collected
  • Evidence of periodic review that data held is still accurate and still needed

  GDPR, Article 5 (Principles relating to processing of personal data) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 6: A valid lawful basis for processing [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 6; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Identify and document a valid lawful basis for each processing activity before it starts — one of consent, contract, legal obligation, vital interests, public task, or legitimate interests. Where the basis is legitimate interests, carry out and keep a balancing assessment weighing the interest against the individual's rights.

  • A record mapping each processing activity to its chosen lawful basis
  • A legitimate-interests assessment where that basis is relied on
  • Evidence the basis was determined before the processing began, and is reviewed if the purpose changes

  GDPR, Article 6 (Lawfulness of processing) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 7: Conditions for valid consent [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 7; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Where processing relies on consent, be able to show the person gave it through a clear affirmative act, freely and for a specific purpose, presented separately from other terms in plain language, and make withdrawing it as easy as giving it.

  • A record of consent capturing who consented, when, to what, and how the request was worded
  • The consent interface or wording showing an unbundled, affirmative opt-in (no pre-ticked boxes)
  • A working withdrawal mechanism and evidence that withdrawal is as easy as consent

  GDPR, Article 7 (Conditions for consent) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 12: Transparent information and communication to data subjects [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 12; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Provide information and handle rights requests in a concise, transparent, intelligible and easily accessible form, in plain language. Respond to a rights request without undue delay and within one month (extendable for complex cases), free of charge in the ordinary case, after taking reasonable steps to verify the requester's identity.

  • A documented rights-request procedure with the one-month timescale and identity-verification step
  • A log of requests received and responded to, showing the response time
  • The plain-language templates used to acknowledge and answer requests

  GDPR, Article 12 (Transparent information, communication and modalities) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 13: Privacy notice when data is collected from the person [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 13; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: When personal data is collected directly from the individual, give them at the point of collection the required information: who the controller is, the purposes and lawful basis, recipients, any transfers abroad, the retention period, their rights, and the source and consequences where relevant.

  • A privacy notice presented at the point of collection covering the Article 13 information
  • Evidence of where and when the notice is shown in the collection flow
  • A version history of the notice showing it is kept current as processing changes

  GDPR, Article 13 (Information to be provided where data is collected from the data subject) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 14: Privacy notice when data is obtained indirectly [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 14; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: When personal data is obtained from someone other than the individual, provide the required information within a reasonable period (at the latest within one month, or at first contact or disclosure), including the categories of data and the source it came from, unless a recognised exception applies.

  • A privacy notice for indirectly obtained data covering the Article 14 information, including the source
  • A record of how and when that notice reaches the individual within the required period
  • A note of any exception relied on for not providing the information, with its justification

  GDPR, Article 14 (Information to be provided where data has not been obtained from the data subject) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 15: Right of access [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 15; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Be able to confirm whether you process an individual's data and, on request, give them a copy of that data together with the supporting information: the purposes, categories, recipients, retention, their rights, and any transfers or automated decision-making.

  • A subject-access procedure covering identity verification, search, and the one-month response
  • A worked example or template of an access response including the required supporting information
  • A log showing access requests handled within the timescale

  GDPR, Article 15 (Right of access by the data subject) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 16: Right to rectification [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 16; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Give individuals a way to have inaccurate data about them corrected without undue delay, and to have incomplete data completed, and pass corrections on to recipients where feasible.

  • A rectification procedure and the interface or channel that lets an individual request it
  • A record of corrections made and of downstream recipients notified where feasible
  • Evidence corrections are actioned without undue delay

  GDPR, Article 16 (Right to rectification) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 17: Right to erasure ('right to be forgotten') [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 17; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Be able to erase an individual's data without undue delay where a ground applies (the data is no longer needed, consent is withdrawn and no other basis exists, an objection is upheld, or the processing was unlawful), and where you have made the data public, take reasonable steps to inform other controllers of the erasure request.

  • An erasure procedure setting out the grounds, the exemptions, and how deletion is carried out across systems and backups
  • A record of erasure requests, the decision taken, and the deletion completed
  • Evidence that, where data was made public, reasonable steps were taken to inform other controllers

  GDPR, Article 17 (Right to erasure ('right to be forgotten')) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 18: Right to restriction of processing [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 18; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Give individuals a way to have processing of their data restricted in the defined situations (accuracy contested, processing unlawful but erasure not wanted, data no longer needed by you but needed by them for a claim, or an objection pending), so the data is stored but not otherwise used, and tell them before any restriction is lifted.

  • A restriction procedure describing the triggers and how restricted data is flagged and held
  • A technical means of marking data as restricted so it is not further processed
  • A record of restrictions applied and of the individual being told before a restriction is lifted

  GDPR, Article 18 (Right to restriction of processing) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 20: Right to data portability [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 20; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Where processing is based on consent or a contract and carried out by automated means, provide the individual, on request, with the personal data they gave you in a structured, commonly used, machine-readable format, and transmit it directly to another controller where technically feasible.

  • A portability procedure identifying which processing qualifies (consent or contract, automated)
  • An export capability producing a structured, machine-readable file of the individual's data
  • A record of portability requests handled and of direct transmission where feasible

  GDPR, Article 20 (Right to data portability) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 21: Right to object [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 21; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Let individuals object to processing based on legitimate interests or public task, and stop unless you can show compelling legitimate grounds that override their interests; where personal data is processed for direct marketing, stop on objection with no exception, and make the right to object clear and separate at the latest at first communication.

  • An objection procedure distinguishing marketing objections (always honoured) from other objections
  • A working opt-out for direct marketing and evidence it is presented clearly
  • A record of objections and, where processing continued, the compelling-grounds assessment

  GDPR, Article 21 (Right to object) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 25: Data protection by design and by default [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 25; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Build data protection into the design of systems and set privacy-protective defaults: apply the principles through technical and organisational measures such as minimisation and pseudonymisation from the outset, and by default process only the data needed for each purpose, with access limited accordingly.

  • Design records showing data-protection measures considered and built in at the design stage
  • Default settings that limit collection, retention, and accessibility to what each purpose needs
  • Evidence of pseudonymisation or minimisation techniques applied where appropriate

  GDPR, Article 25 (Data protection by design and by default) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 30: Records of processing activities [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 30; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Maintain a written record of processing activities covering the required detail: the purposes, categories of individuals and data, recipients, any transfers abroad and their safeguards, retention periods where possible, and a general description of the security measures, and make it available to the supervisory authority on request.

  • A record of processing activities (RoPA) covering the Article 30 fields for each activity
  • Evidence the RoPA is kept current as processing changes
  • The processor-side record where you act as a processor for customers

  GDPR, Article 30 (Records of processing activities) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 32: Security of processing [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 32; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Put in place technical and organisational security measures appropriate to the risk — considering encryption and pseudonymisation, the confidentiality, integrity, availability and resilience of systems, the ability to restore data after an incident, and a process to test and evaluate the measures regularly.

  • A documented set of security measures mapped to the risks of the processing
  • Evidence of encryption or pseudonymisation where appropriate, and of access controls
  • Records of a regular process that tests and evaluates the effectiveness of the measures
  • A tested backup and restore capability

  GDPR, Article 32 (Security of processing) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 33: Breach notification to the supervisory authority (72h) [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 33; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Have a procedure to detect a personal-data breach and, where it is likely to result in a risk to individuals, notify the supervisory authority without undue delay and within 72 hours of becoming aware, describing the breach, its likely consequences and the measures taken, and keep an internal record of every breach whether or not it is notified.

  • A breach-response procedure with the 72-hour authority-notification timescale and decision criteria
  • An internal breach register recording every incident, its assessment, and the action taken
  • A notification template capturing the information the authority requires

  GDPR, Article 33 (Notification of a personal data breach to the supervisory authority) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Article 34: Breach communication to affected individuals [Regulation (EU) 2016/679 (General Data Protection Regulation); Article 34; ELI http://data.europa.eu/eli/reg/2016/679/oj; CELEX 32016R0679]
  What's needed: Where a breach is likely to result in a high risk to individuals, communicate it to those affected without undue delay in plain language, describing the likely consequences and the measures taken and recommended, unless a recognised condition (such as the data being unintelligible through encryption) removes the need.

  • A procedure for assessing high risk and communicating to affected individuals
  • A plain-language individual-notification template
  • A record of the high-risk assessment and of any condition relied on for not communicating

  GDPR, Article 34 (Communication of a personal data breach to the data subject) · Guidance maintained under our internal review, drawn from the cited article; not legal advice.

Source: Regulation (EU) 2016/679, © European Union, https://eur-lex.europa.eu, 1998–2026. Only EU legislation published in the electronic edition of the Official Journal of the European Union is deemed authentic.

123 controls to satisfy

• Clause 4.1: Understanding the organization and its context [ISO/IEC 27001 (information security management system): own-words representation; Clause 4.1]
  What's needed: Run a short, honest context analysis: list the internal issues (team size, architecture, funding stage, remote work) and external issues (customer security demands, cloud dependencies, threat landscape, regulation) that shape what the ISMS must deliver. A certification auditor will expect to see a dated, owner-approved analysis that feeds the risk work and is refreshed when the business changes — the same exercise can also serve an ISO/IEC 42001 AIMS.

  • A dated context analysis naming the organization's specific internal and external issues, with an approver
  • Version history showing the analysis was refreshed after a material change such as a new product or market
  • Traceable links from context issues to the risks, objectives or controls they informed
  • Management review minutes citing the context analysis as an input

  ISO/IEC 27001:2022, Clause 4.1 — Understanding the organization and its context — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 4.2: Needs and expectations of interested parties [ISO/IEC 27001 (information security management system): own-words representation; Clause 4.2]
  What's needed: Build a register of interested parties — customers under security addenda, regulators, investors, employees, cloud and AI providers — and record for each the requirements that matter and which the ISMS commits to address. A certification auditor will expect to see a maintained register: dated, owned, updated when a major contract or new law changes the picture. Convincing versions cite actual contract clauses and statutes; hollow ones say customers expect security.

  • A dated interested-party register with an owner, listing parties and their specific requirements
  • Entries citing concrete sources: contract security clauses, DPAs, statutory duties, investor demands
  • Change history showing updates after a new enterprise contract or regulatory development
  • Cross-references from party requirements to the objectives or controls that address them

  ISO/IEC 27001:2022, Clause 4.2 — Needs and expectations of interested parties — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 4.3: Scope of the information security management system [ISO/IEC 27001 (information security management system): own-words representation; Clause 4.3]
  What's needed: Write a scope statement that names what sits inside the ISMS: the products and services, the people, the offices or remote estate, the cloud infrastructure, and the interfaces and dependencies on providers such as hosting, identity and AI APIs. A certification auditor will expect to see an approved scope with defensible boundaries — exclusions explained, dependencies named — because the certificate describes exactly this scope. Vague boundaries surface at Stage 1.

  • An approved, versioned scope statement naming products, locations, people and infrastructure
  • A statement of interfaces and dependencies on external providers (hosting, identity, AI APIs)
  • Recorded rationale for anything left outside the boundary
  • Evidence the scope was checked against the context and interested-party analyses

  ISO/IEC 27001:2022, Clause 4.3 — Scope of the information security management system — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 4.4: Information security management system [ISO/IEC 27001 (information security management system): own-words representation; Clause 4.4]
  What's needed: Stand up the ISMS as a small set of named, interacting processes — risk assessment, control operation, incident handling, internal audit, management review, improvement — not a folder of policies. A certification auditor will expect to see the processes run and connect: risk outputs drive treatments, monitoring feeds review, review decisions become actions. For a startup, a one-page process map plus operating records beats a heavyweight manual.

  • A process map or manual showing the ISMS processes and how their inputs and outputs connect
  • Operating records from each process: risk register, audit reports, review minutes, improvement tickets
  • Evidence of at least one full plan-operate-check-act cycle, with dates
  • Named owners for each ISMS process

  ISO/IEC 27001:2022, Clause 4.4 — Information security management system — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 5.1: Leadership and commitment [ISO/IEC 27001 (information security management system): own-words representation; Clause 5.1]
  What's needed: This is a management action, not a software task: top management must visibly own the ISMS — set policy and objectives in line with company direction, put security into business decisions, fund it, and back the people running it. A certification auditor will expect to see the conduct, not a signature: minutes where security items were decided and followed up, and budget decisions actually taken. No artifact substitutes for the behavior; the records evidence it.

  • Leadership or board minutes showing security decisions made, with owners and follow-ups closed
  • Budget or headcount records showing resources allocated to the ISMS
  • The policy and objectives signed by top management and referenced in company planning
  • Managers able to describe their security responsibilities without prompting

  ISO/IEC 27001:2022, Clause 5.1 — Leadership and commitment — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 5.2: Policy [ISO/IEC 27001 (information security management system): own-words representation; Clause 5.2]
  What's needed: Publish a short information security policy that top management signs: what security must achieve for the business, a commitment to meet the requirements the organization is subject to and to keep improving, and a frame the objectives hang from. A certification auditor will expect to see it approved, versioned, communicated and easy to find — plus proof people saw it, such as onboarding acknowledgements. One page staff recognize beats ten nobody has read.

  • A dated, versioned policy approved by top management
  • Distribution evidence: onboarding acknowledgements, intranet publication, all-hands announcement
  • The policy's commitments traceable to the stated security objectives
  • Review history showing the policy is revisited on a defined cycle

  ISO/IEC 27001:2022, Clause 5.2 — Policy — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 5.3: Organizational roles, responsibilities and authorities [ISO/IEC 27001 (information security management system): own-words representation; Clause 5.3]
  What's needed: Assign the ISMS roles explicitly: who owns the management system's conformance to the standard, who reports its performance to top management, who owns each control area. In a small team one person may hold several hats — fine, if written down and communicated. A certification auditor will expect to see a responsibility matrix approved by leadership, reflected in job descriptions or onboarding, and staff who know what they are responsible for.

  • An approved responsibility matrix (e.g. RACI) covering ISMS conformance, reporting and control ownership
  • Job descriptions or role charters reflecting the assigned security responsibilities
  • Communication evidence: onboarding materials or announcements naming the roles
  • A named route by which ISMS performance reaches top management, with examples of its use

  ISO/IEC 27001:2022, Clause 5.3 — Organizational roles, responsibilities and authorities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 6.1.1: Actions to address risks and opportunities — general [ISO/IEC 27001 (information security management system): own-words representation; Clause 6.1.1]
  What's needed: Connect planning to context: take the issues from the context analysis and the interested-party register and decide what the ISMS will do about them — which risks and opportunities to act on, how actions land in processes, and how success is judged. A certification auditor will expect to see explicit traceability: each planned action linked to the context item or requirement behind it. The same planning discipline extends to an ISO/IEC 42001 AIMS.

  • A planning record linking context issues and party requirements to concrete actions
  • Risk and opportunity entries with planned actions, owners and target dates
  • Evidence actions were integrated into ISMS processes rather than tracked in a side list
  • Effectiveness checks recorded after actions completed

  ISO/IEC 27001:2022, Clause 6.1.1 — Actions to address risks and opportunities — general — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 6.1.2: Information security risk assessment [ISO/IEC 27001 (information security management system): own-words representation; Clause 6.1.2]
  What's needed: Write down one risk assessment method and use it every time: how risks are identified, the scales for likelihood and impact, the risk-acceptance criteria, and who owns each risk. A certification auditor will expect to see that two assessors would score the same risk the same way — documented criteria, a populated risk register, and consistent results across rounds. A single well-defined method can also serve an ISO/IEC 42001 AIMS.

  • A documented risk assessment methodology with scoring scales and risk-acceptance criteria
  • A risk register with identified risks, analysis, evaluation against criteria, and named owners
  • Two assessment rounds showing comparable, repeatable scoring
  • Approval record for the methodology and its acceptance thresholds

  ISO/IEC 27001:2022, Clause 6.1.2 — Information security risk assessment — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 6.1.3: Information security risk treatment [ISO/IEC 27001 (information security management system): own-words representation; Clause 6.1.3]
  What's needed: For every evaluated risk, choose a treatment — modify, retain, avoid or share — and derive the controls that do the work. Compare the chosen controls against the Annex A catalogue to confirm nothing needed was overlooked, then produce a Statement of Applicability justifying each control's inclusion or exclusion. A certification auditor will expect to see risk owners' signed acceptance of the treatment plan and residual risk; the SoA is what Stage 1 lives on.

  • A risk treatment plan mapping each evaluated risk to its treatment and the controls chosen
  • A Statement of Applicability giving a justification for every control's inclusion or exclusion
  • Risk owners' documented approval of the plan and acceptance of residual risk
  • A comparison record showing the chosen controls were checked against the Annex A catalogue for gaps

  ISO/IEC 27001:2022, Clause 6.1.3 — Information security risk treatment — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 6.2: Information security objectives and planning to achieve them [ISO/IEC 27001 (information security management system): own-words representation; Clause 6.2]
  What's needed: Set a handful of measurable security objectives that flow from the policy — patch latency, incident response time, access-review completion, findings closed — each with a plan: what will be done, resources, owner, deadline, and how the result is judged. A certification auditor will expect to see objectives genuinely measured, results tracked over time, and misses acted on. Three real objectives beat ten aspirational ones nobody measures.

  • A documented set of measurable objectives approved by management, consistent with the policy
  • Per-objective plans naming actions, resources, owner, timeline and evaluation method
  • Measurement results captured on a defined cadence, with trends visible
  • Records of action taken when an objective was missed

  ISO/IEC 27001:2022, Clause 6.2 — Information security objectives and planning to achieve them — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 6.3: Planning of changes [ISO/IEC 27001 (information security management system): own-words representation; Clause 6.3]
  What's needed: Change the ISMS deliberately, not by drift: when the management system itself changes — scope, risk method, tooling, ownership — plan the change, name its purpose and consequences, and decide resources and responsibilities up front. A certification auditor will expect to see planned change records for ISMS-level shifts, such as adopting a new risk tool or extending scope to a new product, distinct from routine IT change tickets, each with an outcome review.

  • Change records for ISMS-level changes with purpose, consequences and resourcing considered
  • Approval by the accountable owner before the change was made
  • Updated documents (scope, SoA, process docs) versioned in step with the change
  • A post-change review confirming the intended result

  ISO/IEC 27001:2022, Clause 6.3 — Planning of changes — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.1: Resources [ISO/IEC 27001 (information security management system): own-words representation; Clause 7.1]
  What's needed: This is a management action, not a software task: someone with budget authority must decide that the ISMS gets real resources — people's time, tooling spend, audit fees, training budget — and keep deciding it as the company grows. A certification auditor will expect to see the decisions themselves: spend records, time allocated to named people, and gaps raised to leadership with a recorded answer. A decision that never reaches minutes or a budget looks like neglect.

  • Budget or spend records covering security tooling, audits and training
  • Allocation of named people's time to ISMS roles, visible in plans or objectives
  • Minutes where a resource gap was raised and management recorded a decision
  • Resourcing revisited at management review, with changes as the company scaled

  ISO/IEC 27001:2022, Clause 7.1 — Resources — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.2: Competence [ISO/IEC 27001 (information security management system): own-words representation; Clause 7.2]
  What's needed: Define what competence each security-affecting role demands — engineers shipping production code, the person running the ISMS, incident responders — then show each person meets it through background, training or supervised experience, and close gaps deliberately. A certification auditor will expect to see competence records per person against defined criteria, not a generic training log: hiring evidence, courses with dates, and an evaluation that training worked.

  • Competence criteria defined for each security-affecting role
  • Per-person records: qualifications, training completions with dates, or documented experience
  • A gap analysis with actions taken (training, mentoring, hiring) and completion evidence
  • Effectiveness evaluation after training, not just attendance records

  ISO/IEC 27001:2022, Clause 7.2 — Competence — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.3: Awareness [ISO/IEC 27001 (information security management system): own-words representation; Clause 7.3]
  What's needed: This is a management action, not a software task: awareness is a state people are in, not a slide deck — management must keep the policy, each person's contribution, and the cost of ignoring it present in how the team works. A certification auditor will expect to see the conduct behind the artifacts: recurring awareness activity, leadership reinforcement, and staff who can say what the policy asks of them. Completion rates show effort; audit interviews test reality.

  • Awareness programme records: sessions held, dates, attendance, topics covered
  • Onboarding evidence that new joiners were introduced to the policy and their part in it
  • Reinforcement traces: all-hands mentions, phishing simulations with follow-up, internal briefs
  • Spot-check or survey results showing staff know the policy and the consequences of not conforming

  ISO/IEC 27001:2022, Clause 7.3 — Awareness — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.4: Communication [ISO/IEC 27001 (information security management system): own-words representation; Clause 7.4]
  What's needed: This is a management action, not a software task: management must decide the ISMS communication plan — what gets said, when, to whom, through which channel — covering internal messages (policy changes, incident notices) and external ones (customer notices, breach reporting duties, the certification body). A certification auditor will expect to see the plan and proof it was followed: a communications matrix with owners, plus communications actually sent on schedule.

  • A communications matrix: message, audience, timing or prompt, channel, owner
  • Examples of internal communications sent (policy updates, security bulletins) with dates
  • External communication records: customer security notices or regulator contact points defined
  • Review evidence that the matrix is kept current as parties and duties change

  ISO/IEC 27001:2022, Clause 7.4 — Communication — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.5.1: Documented information — general [ISO/IEC 27001 (information security management system): own-words representation; Clause 7.5.1]
  What's needed: Keep exactly the documented information the ISMS needs: everything the standard names (scope, policy, objectives, risk records, SoA, audit and review outputs) plus whatever else makes the system work — runbooks, registers, procedures. A certification auditor will expect to see a document inventory mapping each mandated item to a real, current artifact, and evidence of a decision on what extra documentation it keeps. A missing mandated record is a Stage 1 finding.

  • An inventory mapping each document the standard calls for to the live artifact and its location
  • The organization's own list of additional documents it maintains, with rationale
  • Current versions retrievable on request during the audit
  • Each management-system record type with a named home and owner

  ISO/IEC 27001:2022, Clause 7.5.1 — Documented information — general — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.5.2: Creating and updating documented information [ISO/IEC 27001 (information security management system): own-words representation; Clause 7.5.2]
  What's needed: Give every ISMS document a consistent identity and an approval path: title, date, version and owner visible on the artifact; a defined format; and an approval step before publication, with the approver captured. A certification auditor will expect to see the convention working — sampled documents carry identification, show an approver and date, and drafts are distinguishable from approved versions. Docs-as-code with pull-request review handles this neatly.

  • A documented convention for identification: title, version, date, owner
  • Sampled documents showing approval records (sign-off, merged PR, workflow approval) before use
  • Clear separation of draft and approved versions
  • Update history showing re-review when content changed

  ISO/IEC 27001:2022, Clause 7.5.2 — Creating and updating documented information — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.5.3: Control of documented information [ISO/IEC 27001 (information security management system): own-words representation; Clause 7.5.3]
  What's needed: Control ISMS documents through their whole life: available to the people who use them, protected from tampering and loss, with defined handling of distribution, access, storage, retention and disposal — including documents of external origin such as provider attestations. A certification auditor will expect to see access permissions on the document store, version control preventing silent edits, a retention schedule enforced, and current versions easy to find.

  • Access permissions on the document repository matching defined roles
  • Version control or edit history making changes attributable and reversible
  • A retention and disposal schedule with evidence of enforcement
  • External documents (provider reports, attestations) stored and controlled alongside internal ones

  ISO/IEC 27001:2022, Clause 7.5.3 — Control of documented information — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 8.1: Operational planning and control [ISO/IEC 27001 (information security management system): own-words representation; Clause 8.1]
  What's needed: Make the plans operate day to day: implement the processes that carry the Clause 6 actions and security requirements, set criteria for how they run, and keep evidence they ran to those criteria. Control planned changes, review unintended ones, and keep externally provided services — cloud, CI, AI APIs, contractors — under defined control. A certification auditor will expect to see records proving routine execution, plus supplier oversight beyond a signed contract.

  • Operating criteria for key security processes and records showing execution against them
  • Change management records including review of unintended changes and their consequences
  • A register of externally provided processes and services with the controls over each
  • Evidence supplier controls operate: review notes, attestation checks, SLA monitoring

  ISO/IEC 27001:2022, Clause 8.1 — Operational planning and control — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 8.2: Information security risk assessment (operational) [ISO/IEC 27001 (information security management system): own-words representation; Clause 8.2]
  What's needed: Run the risk assessment on a schedule and on prompt: at planned intervals — for most startups at least annually — and whenever something significant shifts: a new product, a major customer, a new AI dependency, an incident, a re-architecture. A certification auditor will expect to see documented results of each round retained, dated and comparable with prior rounds under the same method, and evidence that event-driven reassessments actually happen.

  • A schedule defining assessment intervals and the events that prompt reassessment
  • Dated assessment results at each planned interval, retained in the risk register
  • An event-driven assessment following a significant change, with the change named
  • Comparable results across rounds: same method, same scales, trends visible

  ISO/IEC 27001:2022, Clause 8.2 — Information security risk assessment (operational) — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 8.3: Information security risk treatment (operational) [ISO/IEC 27001 (information security management system): own-words representation; Clause 8.3]
  What's needed: Execute the treatment plan and keep the receipts: implement the chosen controls, track each treatment to completion, and document the results — what was implemented, when, by whom, and what residual risk remains. A certification auditor will expect to see the plan crossing into reality: tickets closing against treatment actions, the risk register updated as treatments land, and slipped items rescheduled with the risk owner's knowledge rather than quietly forgotten.

  • Treatment actions tracked to completion in tickets or a plan with dates and owners
  • Documented results per treatment: what changed, with evidence of the control operating
  • Risk register entries updated to reflect post-treatment residual risk
  • Slipped or deferred treatments re-approved by the risk owner

  ISO/IEC 27001:2022, Clause 8.3 — Information security risk treatment (operational) — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 9.1: Monitoring, measurement, analysis and evaluation [ISO/IEC 27001 (information security management system): own-words representation; Clause 9.1]
  What's needed: Decide what the ISMS measures and stick to it: indicators tied to the objectives and key controls — patch latency, access-review completion, incident metrics, control test results — with method, cadence, who measures and who evaluates defined. A certification auditor will expect to see documented results over time and, the part startups miss, evaluation: someone reading the numbers, judging effectiveness, and feeding conclusions into management review.

  • A monitoring plan: what is measured, method, frequency, who measures, who evaluates
  • Time-series results retained as documented evidence
  • Written evaluation of performance and system effectiveness, not raw dashboards alone
  • Evaluation conclusions traceable into management review inputs and actions

  ISO/IEC 27001:2022, Clause 9.1 — Monitoring, measurement, analysis and evaluation — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 9.2.1: Internal audit — general [ISO/IEC 27001 (information security management system): own-words representation; Clause 9.2.1]
  What's needed: Audit yourselves before the certification body does: run internal audits at planned intervals checking conformance both to your own policies and to the standard, and whether the system is genuinely implemented and maintained. A certification auditor will expect to see audit reports with findings and sampled evidence — an internal audit that found nothing raises eyebrows. One combined programme can cover an ISO/IEC 27001 ISMS and an ISO/IEC 42001 AIMS together.

  • Internal audit reports with scope, criteria, evidence examined, findings and conclusions
  • Coverage of both the organization's own requirements and the standard's clauses
  • Findings tracked to corrective action with closure evidence
  • At least one full internal audit completed before the Stage 2 certification audit

  ISO/IEC 27001:2022, Clause 9.2.1 — Internal audit — general — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 9.2.2: Internal audit programme [ISO/IEC 27001 (information security management system): own-words representation; Clause 9.2.2]
  What's needed: Build an audit programme, not a one-off: schedule which parts of the ISMS get audited when, weighted by risk and past results; define criteria and scope for each audit; and solve the small-company objectivity problem — auditors must not review their own work, so use a cross-functional peer or an external contractor. A certification auditor will expect to see the programme document, objectivity safeguards recorded, and results reported to management.

  • A documented audit programme covering the ISMS across the certification cycle, risk-weighted
  • Per-audit records of defined criteria and scope
  • Evidence of auditor objectivity: an independence declaration or use of an external auditor
  • Audit results formally reported to management, with the report retained

  ISO/IEC 27001:2022, Clause 9.2.2 — Internal audit programme — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 9.3.1: Management review — general [ISO/IEC 27001 (information security management system): own-words representation; Clause 9.3.1]
  What's needed: This is a management action, not a software task: top management must actually sit down at planned intervals and judge whether the ISMS still fits the business, covers what it must, and works — a decision-making review, not a status readout. A certification auditor will expect to see the review held on schedule with the right people present, conclusions reached on suitability, adequacy and effectiveness, and leadership treating it as their meeting.

  • A defined review cadence with meetings held on schedule, dated
  • Attendance showing top management present, not only the security lead
  • Minutes recording judgements on suitability, adequacy and effectiveness
  • Follow-through: prior review actions visible and closed in the next cycle

  ISO/IEC 27001:2022, Clause 9.3.1 — Management review — general — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 9.3.2: Management review inputs [ISO/IEC 27001 (information security management system): own-words representation; Clause 9.3.2]
  What's needed: This is a management action, not a software task: the review is only as good as what leadership considers — status of prior actions, changes in context, interested-party feedback, performance data (nonconformities, monitoring results, audit results, objectives), the state of risks and the treatment plan, and improvement opportunities. A certification auditor will expect to see an input pack showing each area was put before management, with gaps treated as findings.

  • A review input pack covering each input area, circulated before the meeting
  • Status of actions from previous reviews, explicitly reported
  • Performance data included: audit results, nonconformities, monitoring trends, objectives
  • Risk register and treatment plan status presented, alongside interested-party feedback

  ISO/IEC 27001:2022, Clause 9.3.2 — Management review inputs — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 9.3.3: Management review results [ISO/IEC 27001 (information security management system): own-words representation; Clause 9.3.3]
  What's needed: This is a management action, not a software task: the review must end in recorded decisions — what improves, what changes the ISMS undergoes, who owns each action and by when. A certification auditor will expect to see minutes that read as decisions, not summaries: improvement items with owners and dates, changes to scope, resources or processes, and a trail showing the decisions were executed before the next review. No outputs means the review did not happen.

  • Minutes recording explicit decisions on continual improvement and ISMS changes
  • Each decision assigned an owner and a target date
  • Actions tracked to closure in a visible system (tickets, action log)
  • The next review's inputs confirming prior decisions were carried out

  ISO/IEC 27001:2022, Clause 9.3.3 — Management review results — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 10.1: Continual improvement [ISO/IEC 27001 (information security management system): own-words representation; Clause 10.1]
  What's needed: Make improvement a running loop, not a slogan: gather candidates from audits, incidents, monitoring, reviews and staff suggestions, decide which to pursue, and land them as concrete changes to the ISMS's suitability, adequacy or effectiveness. A certification auditor will expect to see an improvement log with items moving to done — a metric that got better, a process that got simpler, a control strengthened after a near miss — proof the system beats last year's.

  • An improvement log with sources, decisions, owners and completion dates
  • Examples of completed improvements with the measurable difference they made
  • Improvement items originating from varied sources: audit, incident, monitoring, staff input
  • Management review minutes showing improvement decisions and their follow-up

  ISO/IEC 27001:2022, Clause 10.1 — Continual improvement — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 10.2: Nonconformity and corrective action [ISO/IEC 27001 (information security management system): own-words representation; Clause 10.2]
  What's needed: Treat every nonconformity as a loop to close: contain and correct the immediate issue, decide whether the cause deserves elimination — root-cause analysis proportionate to impact — implement corrective action, and verify it prevented recurrence. A certification auditor will expect to see a nonconformity register where entries progress from detection through correction, cause analysis, action and effectiveness check, including ones the organization found itself.

  • A nonconformity register with detection source, correction, cause analysis and status
  • Root-cause records proportionate to the issue's effects
  • Corrective actions implemented with owner, date and linked change evidence
  • Effectiveness reviews recorded after a defined interval, reopening actions that failed
  • Self-identified nonconformities present, not only audit-raised ones

  ISO/IEC 27001:2022, Clause 10.2 — Nonconformity and corrective action — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.1: Policies for information security [ISO/IEC 27001 (information security management system): own-words representation; A.5.1]
  What's needed: Write one top-level information security policy plus the topic policies that govern how you work — access control, cryptography, secure development, supplier security — and have management approve each. Publish them where staff genuinely read them and re-approve after significant change or on a set cadence. A certification auditor will expect to see approval records, version history, and distribution evidence; an unread PDF in a forgotten folder convinces no one.

  • A dated, versioned information security policy signed off by management
  • Topic-specific policies (access control, crypto, development, supplier) each with an owner and approval record
  • Evidence of publication and staff acknowledgement, such as onboarding sign-offs or intranet read receipts
  • Review log showing the last scheduled review, who ran it, and what changed

  ISO/IEC 27001:2022, A.5.1 — Policies for information security — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.2: Information security roles and responsibilities [ISO/IEC 27001 (information security management system): own-words representation; A.5.2]
  What's needed: Name real people against real security duties. In a small SaaS company one person often carries several hats — that is fine, but write it down: who owns the ISMS, who owns risk decisions, who handles incidents, who administers access, who talks to authorities. A certification auditor will expect to see a roles matrix that matches reality — they will interview the named people and check that each can describe the duty they supposedly hold.

  • A security roles and responsibilities matrix naming individuals, dated and approved
  • Role descriptions or an org chart showing security duties assigned, including deputies for key roles
  • Onboarding records showing role holders were told of and accepted their security responsibilities
  • Minutes or tickets showing the named owners actually exercising the duty (risk sign-offs, incident leads)

  ISO/IEC 27001:2022, A.5.2 — Information security roles and responsibilities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.3: Segregation of duties [ISO/IEC 27001 (information security management system): own-words representation; A.5.3]
  What's needed: Identify duty pairs where one person could do damage undetected — deploying their own unreviewed code, approving their own access, administering both production and its audit logs — and separate them. Where a small team cannot split a duty, add a compensating control: enforced peer review, dual approval, or independent monitoring of the privileged action. A certification auditor will expect to see the conflict analysis and proof the mechanism cannot be bypassed.

  • A documented analysis of conflicting duties with the separation or compensating control chosen for each
  • Branch-protection or pipeline settings blocking self-approved changes to production
  • Access records showing admin rights and audit-log control are not held by the same unchecked person
  • Sampled change or access approvals showing a second person genuinely involved

  ISO/IEC 27001:2022, A.5.3 — Segregation of duties — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.4: Management responsibilities [ISO/IEC 27001 (information security management system): own-words representation; A.5.4]
  What's needed: This is a management action, not a software task: this control lives in whether managers actually hold personnel to the security policies day to day, and no document substitutes for that conduct. A certification auditor will expect to see the behaviour evidenced in records: managers briefing joiners on security duties, follow-ups when practice slips, security expectations in objectives or reviews, and leadership minutes showing decisions resourced and carried out.

  • Manager-led onboarding records covering security duties, with dates and attendee names
  • A tracked case where a policy lapse was raised by a manager and the correction followed through
  • Management minutes with security decisions, owners, deadlines and their completion status
  • Periodic reminders or all-hands items reinforcing policy expectations, with dates

  ISO/IEC 27001:2022, A.5.4 — Management responsibilities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.5: Contact with authorities [ISO/IEC 27001 (information security management system): own-words representation; A.5.5]
  What's needed: Work out in advance which authorities you would have to contact and how — data protection authorities for breach notification, law enforcement for criminal activity, sector regulators, national CERTs — and keep a current contact sheet naming who makes the call and within what timeframe. A certification auditor will expect to see the maintained list, its link to your incident response process, and evidence it is reviewed so numbers and duties do not go stale.

  • A dated authority contact list naming each body, the trigger for contact, and the internal owner
  • Incident response procedure referencing the authority contacts and notification deadlines
  • Review record showing the contact list was checked and updated within the last cycle
  • Where contact occurred, a record of the notification made and the authority's response

  ISO/IEC 27001:2022, A.5.5 — Contact with authorities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.6: Contact with special interest groups [ISO/IEC 27001 (information security management system): own-words representation; A.5.6]
  What's needed: Keep live channels into the wider security community so threat and practice knowledge reaches you early: cloud provider security bulletins, OWASP or language-ecosystem advisories, an ISAC or founder security community, vendor mailing lists. For a small team this is subscriptions plus a habit of reading them. A certification auditor will expect to see the maintained channel list and examples where something learned externally changed what you did internally.

  • A list of memberships, forums and advisory subscriptions with the owner for each channel
  • Tickets or changes traceable to an external advisory or community alert
  • Evidence of ongoing engagement, such as digest reviews or forum participation records
  • Periodic confirmation the channel list is still current and monitored

  ISO/IEC 27001:2022, A.5.6 — Contact with special interest groups — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.7: Threat intelligence [ISO/IEC 27001 (information security management system): own-words representation; A.5.7]
  What's needed: Set up a lightweight threat intelligence loop: collect advisories from your actual stack (cloud provider, OS and dependency feeds, CISA KEV, GitHub security alerts), assess which items touch your systems, and turn hits into patches, detections or config changes. A certification auditor will expect to see the loop operating — sources defined, triage on a rhythm, and a trail from a specific advisory to the mitigation you shipped, not a folder of unread feeds.

  • A documented list of threat intelligence sources matched to your technology stack
  • Triage records showing advisories assessed for impact, with decisions and dates
  • Tickets linking specific advisories to patches, detection rules or configuration changes
  • A recurring review slot or automation run demonstrating the loop operates continuously

  ISO/IEC 27001:2022, A.5.7 — Threat intelligence — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.8: Information security in project management [ISO/IEC 27001 (information security management system): own-words representation; A.5.8]
  What's needed: Build security into how projects are run, not bolted on at the end. For a startup this means security questions at kickoff (data touched, new attack surface, third parties), security acceptance items in the definition of done, and a recorded risk decision for anything significant. A certification auditor will expect to see the checkpoint embedded in your delivery workflow — ticket templates, design review notes — and sampled projects where it demonstrably ran.

  • Project or feature template containing security checkpoint questions and sign-off fields
  • Design or kickoff records for sampled projects showing security risks raised and addressed
  • Definition-of-done or release checklist including the security acceptance items
  • A recorded risk decision from a recent project, with the owner who accepted it

  ISO/IEC 27001:2022, A.5.8 — Information security in project management — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.9: Inventory of information and other associated assets [ISO/IEC 27001 (information security management system): own-words representation; A.5.9]
  What's needed: Maintain one inventory of the information and supporting assets that matter: datasets and customer data stores, code repositories, cloud accounts, SaaS tools, laptops, ML models and keys — each with a named owner. For a small company, generate what you can from your MDM, cloud and IdP, and reconcile the rest on a schedule. A certification auditor will expect to see a current, owned inventory and will test it by picking real systems and checking they are on it.

  • An asset inventory covering information, systems, SaaS, devices and models, each row with a named owner
  • Evidence of automated population or reconciliation from MDM, cloud and identity provider exports
  • A dated review confirming the inventory was checked for accuracy, with corrections logged
  • Joiner/leaver or procurement process steps that add and retire inventory entries

  ISO/IEC 27001:2022, A.5.9 — Inventory of information and other associated assets — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.10: Acceptable use of information and other associated assets [ISO/IEC 27001 (information security management system): own-words representation; A.5.10]
  What's needed: Publish clear rules for how people may use company information and assets — laptops, SaaS accounts, customer data, source code — and for handling each classification level. Cover the edges a startup actually hits: personal devices, browser extensions, and pasting data into external AI tools. A certification auditor will expect to see the rules acknowledged by each person on joining and evidence of enforcement when the rules are broken, not just a policy on file.

  • A dated acceptable use policy covering devices, SaaS, customer data and external AI tools
  • Signed or logged acknowledgements from all current staff and contractors
  • Handling rules mapped to classification levels, published where staff work
  • A record of a violation handled — what was detected, the response, and the correction

  ISO/IEC 27001:2022, A.5.10 — Acceptable use of information and other associated assets — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.11: Return of assets [ISO/IEC 27001 (information security management system): own-words representation; A.5.11]
  What's needed: Make asset return a controlled step in every offboarding and role change: laptops and tokens back, repositories and drives transferred, keys and credentials revoked, and company data on personal devices removed. Run it from a checklist with a named owner and a deadline tied to the leaver's last day. A certification auditor will expect to see completed checklists for actual leavers and will reconcile them against HR departure records to find the one that slipped.

  • An offboarding checklist covering devices, data, credentials and physical items, with owner and due date
  • Completed checklists for recent leavers, signed off and dated
  • Reconciliation of HR departure records against completed returns for the review period
  • Records of remote wipe or data removal where a personal device held company information

  ISO/IEC 27001:2022, A.5.11 — Return of assets — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.12: Classification of information [ISO/IEC 27001 (information security management system): own-words representation; A.5.12]
  What's needed: Adopt a small classification scheme you can actually operate — typically Public, Internal, Confidential, Restricted — with criteria based on confidentiality, integrity, availability and customer and regulatory demands. Have asset owners classify what they own and record it in the inventory. A certification auditor will expect to see the scheme documented, the inventory carrying the levels, and consistent treatment: two similar datasets classed the same way.

  • A documented classification scheme with criteria and examples for each level
  • Asset inventory entries showing the classification assigned by the named owner
  • Handling requirements defined per level (storage, sharing, retention)
  • Evidence of reclassification when an asset's sensitivity changed, with date and reason

  ISO/IEC 27001:2022, A.5.12 — Classification of information — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.13: Labelling of information [ISO/IEC 27001 (information security management system): own-words representation; A.5.13]
  What's needed: Give people a defined, low-friction way to mark information with its classification: header/footer conventions, email or drive sensitivity labels, tags on cloud buckets and repositories. For a startup, automate where the platform allows (default labels, template documents) so labels happen without heroics. A certification auditor will expect to see the procedure written down, and will sample real documents, buckets and repos to check the marks are actually there.

  • A labelling procedure mapping each classification level to its digital label or tag format
  • Sampled documents and emails carrying the correct sensitivity labels
  • Cloud storage buckets or repositories tagged with their classification
  • Templates or platform defaults that pre-label newly created content

  ISO/IEC 27001:2022, A.5.13 — Labelling of information — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.14: Information transfer [ISO/IEC 27001 (information security management system): own-words representation; A.5.14]
  What's needed: Define approved channels for moving information at each classification level — internal, customer, supplier — and close the ad-hoc ones. Encrypt transfers of sensitive data, sign NDAs or data-processing terms before customer data leaves your boundary, and ban untracked exports to personal accounts or unapproved tools. A certification auditor will expect to see the transfer rules, the agreements behind external flows, and settings that enforce the channel choices.

  • Transfer rules naming approved channels and encryption expectations per classification level
  • Signed NDAs or data-processing agreements covering recurring external transfers
  • Technical controls restricting risky channels, such as blocked public sharing or DLP alerts
  • A logged example of a sensitive transfer performed through the approved secure channel

  ISO/IEC 27001:2022, A.5.14 — Information transfer — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.15: Access control [ISO/IEC 27001 (information security management system): own-words representation; A.5.15]
  What's needed: Write an access control policy that states the rules of the game: least privilege, need-to-know, deny by default, and how physical and logical access decisions get made and by whom. Then make your systems match it — role-based groups in your IdP, production access granted only through the defined route. A certification auditor will expect to see the policy and then test it against reality: pick users and check entitlements trace back to a rule and an approval.

  • A dated access control policy stating least-privilege and deny-by-default rules, with an owner
  • Role or group definitions in the identity provider mapped to job functions
  • Access request and approval records for sampled grants, traceable to the policy rules
  • Evidence physical access (office, server areas) follows the same documented rules

  ISO/IEC 27001:2022, A.5.15 — Access control — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.16: Identity management [ISO/IEC 27001 (information security management system): own-words representation; A.5.16]
  What's needed: Run every identity through a managed life cycle: created on a verified joiner, unique to one person, changed on role moves, disabled on exit. Centralize through SSO so there is one authoritative directory, ban shared logins (or document the rare exception with an owner), and give each service account a human owner and review date. A certification auditor will expect to see the life cycle procedure and clean joiner-mover-leaver records against the directory.

  • Identity life cycle procedure covering creation, change, suspension and removal
  • Directory export showing unique named accounts, with any shared accounts justified and owned
  • Joiner, mover and leaver tickets reconciled against directory changes for the period
  • Service account register naming the responsible owner and last review date for each

  ISO/IEC 27001:2022, A.5.16 — Identity management — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.17: Authentication information [ISO/IEC 27001 (information security management system): own-words representation; A.5.17]
  What's needed: Control how authentication secrets are issued, stored and changed. Give staff a password manager and rules that make strong practice easy; enforce MFA on everything that matters; issue initial credentials securely with forced change; keep API keys and machine secrets in a vault, out of code and chat, rotated on exposure or departure. A certification auditor will expect to see the enforced settings and the vault, plus evidence staff were briefed on handling secrets.

  • Password and MFA settings enforced in the identity provider, shown by configuration export
  • Password manager deployed to all staff, with enrolment records
  • Secrets vault holding API keys and service credentials, with access logs and rotation dates
  • Guidance issued to personnel on handling credentials, with acknowledgement records
  • A rotation record following a suspected exposure or a leaver with secret access

  ISO/IEC 27001:2022, A.5.17 — Authentication information — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.18: Access rights [ISO/IEC 27001 (information security management system): own-words representation; A.5.18]
  What's needed: Manage access rights as a life cycle, not a one-time grant: provision from the role's entitlement set, adjust on every role change, and revoke within a set target on departure. Review access on a schedule — quarterly for production and admin rights is a defensible startup rhythm — and record what each review found and removed. A certification auditor will expect to see review outputs with actual revocations and leaver access removed within your stated deadline.

  • Provisioning records showing grants matched to the role's defined entitlements with approval
  • Completed access reviews with reviewer, date, findings and the removals executed
  • Leaver revocation records showing time from departure to access removal against the target
  • Records of rights adjusted on internal role changes, not just accumulated

  ISO/IEC 27001:2022, A.5.18 — Access rights — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.19: Information security in supplier relationships [ISO/IEC 27001 (information security management system): own-words representation; A.5.19]
  What's needed: Stand up a supplier security process sized to your reality: register every supplier and subprocessor touching your data or production, tier them by risk, run due diligence before onboarding the important ones, and revisit the assessment on renewal or incident. For a small SaaS company the register doubles as your subprocessor list for customers. A certification auditor will expect to see the process documented and a recent supplier that demonstrably went through it.

  • A supplier and subprocessor register with data touched, risk tier and named owner per supplier
  • Due diligence records for high-risk suppliers, such as reviewed SOC 2 reports or questionnaires
  • A documented onboarding decision for a recent supplier showing the process was followed
  • Re-assessment records at renewal or after a supplier incident, with the outcome

  ISO/IEC 27001:2022, A.5.19 — Information security in supplier relationships — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.20: Addressing information security within supplier agreements [ISO/IEC 27001 (information security management system): own-words representation; A.5.20]
  What's needed: Tier suppliers by the data and access each touches, then put matching security terms into every agreement instead of signing vendor paper unread. For a small SaaS or AI company that means DPAs and security clauses with cloud, model-API and analytics vendors covering confidentiality, breach-notification windows, subprocessor changes and audit rights. A certification auditor will expect the tiering rationale and signed clauses that track it, not one generic template.

  • A supplier register tiering vendors by data sensitivity and access, with an owner and review date
  • Signed DPAs or security addenda for high-tier suppliers covering breach notice and subprocessor terms
  • A contract checklist showing which security clauses each tier gets, with dated approvals
  • Records of a new supplier onboarded through the process, from risk tier to executed agreement

  ISO/IEC 27001:2022, A.5.20 — Addressing information security within supplier agreements — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.21: Managing information security in the ICT supply chain [ISO/IEC 27001 (information security management system): own-words representation; A.5.21]
  What's needed: Look past your direct vendors to the chain behind them: model providers behind an API reseller, open-source packages inside your build, the hosting under your cloud. Define how you vet provenance, pin and verify dependencies, receive vulnerability notices, and get told when a supplier swaps its subproviders. A certification auditor will expect supply-chain requirements written into agreements and a working record of dependency and subprocessor tracking.

  • Supply-chain security requirements passed down in supplier agreements, including subprovider-change notice
  • A dependency inventory or SBOM for shipped services, regenerated by the build pipeline with dates
  • Vulnerability alerts from suppliers or scanners triaged in tickets with outcomes
  • Records of provenance checks on critical components such as base images or model APIs

  ISO/IEC 27001:2022, A.5.21 — Managing information security in the ICT supply chain — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.22: Monitoring, review and change management of supplier services [ISO/IEC 27001 (information security management system): own-words representation; A.5.22]
  What's needed: Set a cadence to check suppliers still deserve the trust you placed: re-collect SOC 2 reports or certificates annually for high-tier vendors, watch status pages and incident notices, and log service reviews with findings and actions. Treat supplier changes — new subprocessors, changed terms, degraded SLAs — as events to evaluate, not emails to archive. A certification auditor will expect dated review records and a supplier issue that drew a documented follow-up.

  • An annual supplier review log listing evidence collected, reviewer, date and outcome per high-tier vendor
  • Current attestation reports or certificates on file for critical suppliers, with expiry tracked
  • Tickets showing supplier incidents or subprocessor changes evaluated, with decisions recorded
  • A follow-up action from a supplier review tracked to closure

  ISO/IEC 27001:2022, A.5.22 — Monitoring, review and change management of supplier services — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.23: Information security for use of cloud services [ISO/IEC 27001 (information security management system): own-words representation; A.5.23]
  What's needed: Write down how cloud services enter and leave your stack: who approves a new service, the security requirements it must meet, how responsibilities split between you and the provider, and how you would exit — data export, deletion confirmation, credential revocation. A certification auditor will expect to see the process operating: an approved-services list, shared-responsibility notes for key providers, and an exit plan that names real steps, not a slogan.

  • A cloud services procedure covering acquisition, use, management and exit, dated and approved
  • An inventory of cloud services in use with owner, data held and approval reference
  • Shared-responsibility documentation for key providers noting which controls you operate
  • An exit plan for a critical provider covering data export, deletion evidence and account closure

  ISO/IEC 27001:2022, A.5.23 — Information security for use of cloud services — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.24: Information security incident management planning and preparation [ISO/IEC 27001 (information security management system): own-words representation; A.5.24]
  What's needed: Prepare for incidents before one happens: an incident-response plan naming roles and deputies, a severity scheme, escalation paths, communication templates for customers and authorities, and tooling ready — an incident channel, a tracker, contact lists. Run at least one tabletop exercise a year and record what it exposed. A certification auditor will expect to see the plan, evidence people know their roles, and exercise notes with improvements actually made.

  • An incident response plan with named roles, severity levels and escalation paths, versioned and approved
  • Communication templates for customer and regulator notification, with owners
  • Tabletop exercise records with date, participants, scenario and improvement actions
  • On-call or contact rosters kept current, with a change history

  ISO/IEC 27001:2022, A.5.24 — Information security incident management planning and preparation — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.25: Assessment and decision on information security events [ISO/IEC 27001 (information security management system): own-words representation; A.5.25]
  What's needed: Not every alert is an incident: define triage criteria that turn an event into a classification decision — what data, systems and users are affected, and thresholds that make it an incident. Name who decides and log every decision, including events closed as noise and why. A certification auditor will expect to see the criteria written down and a trail of real triage decisions; a queue where nothing was ever declared an incident reads as a process that does not run.

  • Documented triage criteria distinguishing events from incidents, with severity thresholds
  • A log of events reviewed, showing decision, decider and timestamp for each
  • At least one event escalated to incident status with the rationale recorded
  • Records of events closed as non-incidents with the reasoning kept

  ISO/IEC 27001:2022, A.5.25 — Assessment and decision on information security events — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.26: Response to information security incidents [ISO/IEC 27001 (information security management system): own-words representation; A.5.26]
  What's needed: When an incident is declared, the response should follow the plan, not improvisation: contain, collect evidence, eradicate, recover, and notify whoever your contracts and regulators expect, within deadline. Keep a timestamped incident record as you go — actions, decisions, who did what — because reconstruction after the fact convinces no one. A certification auditor will expect per-incident records that track the documented procedure, including notification timing.

  • Incident tickets showing containment, eradication and recovery steps with timestamps and owners
  • A notification decision record per incident, with recipients, deadlines and when notice went out
  • Evidence-handling notes linked from the incident record
  • A closed incident reviewed and signed off by the incident lead

  ISO/IEC 27001:2022, A.5.26 — Response to information security incidents — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.27: Learning from information security incidents [ISO/IEC 27001 (information security management system): own-words representation; A.5.27]
  What's needed: Close the loop after each incident: hold a blameless post-incident review, write down root cause and contributing factors, and convert lessons into tracked changes — a new alert, a hardened configuration, a revised runbook, an updated risk entry. A certification auditor will expect to see review notes for real incidents and the improvement actions carried to completion; a pile of retrospectives with no closed actions shows learning that never landed.

  • Post-incident review notes with root cause, contributing factors and attendees
  • Improvement actions in the tracker linked to the incident, with closure evidence
  • Risk register entries updated or added as a result of incident lessons
  • Trend notes showing recurring incident themes reviewed with management

  ISO/IEC 27001:2022, A.5.27 — Learning from information security incidents — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.28: Collection of evidence [ISO/IEC 27001 (information security management system): own-words representation; A.5.28]
  What's needed: Write a forensic collection procedure you could follow at 2 a.m.: what to preserve first (cloud audit logs, access logs, volume snapshots, chat threads), how integrity is kept — hash at capture, store in write-once or restricted storage — and who may collect, with a chain-of-custody log naming every handler. A certification auditor will expect the procedure plus evidence it was exercised in an incident or drill, since it also underpins your incident documentation.

  • A documented evidence-collection procedure listing sources to preserve and the capture order
  • A chain-of-custody template and a completed example naming handlers, times and storage location
  • Hash records for captured artifacts made at collection time
  • An access-restricted evidence store with retention and write-once or immutability settings
  • A drill or incident record showing the procedure was actually followed

  ISO/IEC 27001:2022, A.5.28 — Collection of evidence — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.29: Information security during disruption [ISO/IEC 27001 (information security management system): own-words representation; A.5.29]
  What's needed: Decide in advance which protections survive a disruption: access control, logging and encryption must not be dropped to get service back during an outage or failover. Write those expectations into continuity and DR plans — degraded-mode rules, an emergency-access procedure with after-the-fact review, what may be bypassed and who approves. A certification auditor will expect continuity plans that address security explicitly and exercise records showing it held.

  • Continuity and DR plans with a section stating the security controls maintained in degraded mode
  • An emergency-access ('break-glass') procedure with approval and after-the-fact review steps
  • Exercise or incident records confirming logging and access control stayed on during failover
  • A decision log of any control bypassed during disruption, with review outcome

  ISO/IEC 27001:2022, A.5.29 — Information security during disruption — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.30: ICT readiness for business continuity [ISO/IEC 27001 (information security management system): own-words representation; A.5.30]
  What's needed: Turn continuity intent into tested ICT capability: set recovery time and recovery point objectives per critical service, implement backups and, where justified, failover to meet them, and test on a schedule — restore from backup, fail over, time it, compare results to objectives. A certification auditor will expect documented RTO/RPO targets, test records with measured results, and fixes where a test missed its target; untested backups are hope, not readiness.

  • Documented RTO/RPO objectives per critical service, approved by management
  • Backup restoration test records with date, duration and result against target
  • A failover or DR exercise report with gaps found and actions tracked
  • Monitoring or alerts confirming backup jobs succeed, with failures ticketed

  ISO/IEC 27001:2022, A.5.30 — ICT readiness for business continuity — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.31: Legal, statutory, regulatory and contractual requirements [ISO/IEC 27001 (information security management system): own-words representation; A.5.31]
  What's needed: Build a register of the legal, regulatory and contractual obligations that bind your security — GDPR and the privacy statutes where your users are, sector rules, plus customer-contract security clauses — each mapped to how you meet it and to an owner. Review it on a schedule and when you enter new markets or sign unusual terms. A certification auditor will expect the register, its review history, and the mapping from each obligation to the controls that answer it.

  • A legal and contractual obligations register with owner, source and the meeting mechanism per entry
  • Dated review records for the register, including updates after new markets or contracts
  • Customer-contract security clauses extracted and mapped to internal controls
  • Sign-off from management or counsel on the register's current version

  ISO/IEC 27001:2022, A.5.31 — Legal, statutory, regulatory and contractual requirements — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.32: Intellectual property rights [ISO/IEC 27001 (information security management system): own-words representation; A.5.32]
  What's needed: Protect intellectual property in both directions: respect what you license — track software and SaaS licenses, scan open-source dependencies for license terms you can honor — and protect your own code, models and data through contracts, access control and marking. A certification auditor will expect a license inventory, dependency license scans wired into the build, and contract terms settling IP ownership with staff, contractors and suppliers.

  • A software and SaaS license inventory reconciled against actual use, with review dates
  • Dependency license scan results from the pipeline, with flagged licenses resolved in tickets
  • IP assignment and confidentiality terms in employment and contractor agreements
  • Records of permissions for third-party content or training data in use

  ISO/IEC 27001:2022, A.5.32 — Intellectual property rights — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.33: Protection of records [ISO/IEC 27001 (information security management system): own-words representation; A.5.33]
  What's needed: Decide which records to keep and for how long, and protect them for that life: a retention schedule covering security records, contracts, finance and HR material; access-controlled, backed-up storage; tamper-evidence for records whose integrity matters, such as audit logs; and controlled disposal when retention ends. A certification auditor will expect the schedule, evidence the protections operate, and disposal records rather than data kept forever by default.

  • A retention schedule listing record types, retention periods and disposal method, approved and dated
  • Access-control evidence for record stores, showing who can read or alter each class
  • Immutability or tamper-evidence settings on audit-relevant records
  • Disposal logs showing records deleted on schedule, with authorization

  ISO/IEC 27001:2022, A.5.33 — Protection of records — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.34: Privacy and protection of PII [ISO/IEC 27001 (information security management system): own-words representation; A.5.34]
  What's needed: Know what personal data you hold and meet the privacy rules that attach to it: keep a data inventory or processing register naming the personal data, purposes, storage and recipients; put DPAs in place with processors; run a procedure for data-subject requests with deadlines; and publish accurate privacy notices. A certification auditor will expect the inventory, executed DPAs, a handled-request example, and notices that match what the systems actually do.

  • A personal-data inventory or processing register with purposes, locations and recipients
  • Executed DPAs with processors and subprocessors, tracked with renewal dates
  • A data-subject request procedure and a completed request record handled within deadline
  • Privacy notices versioned and checked against actual processing, including AI features

  ISO/IEC 27001:2022, A.5.34 — Privacy and protection of PII — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.35: Independent review of information security [ISO/IEC 27001 (information security management system): own-words representation; A.5.35]
  What's needed: Have someone without ownership of the ISMS review it at planned intervals and after significant change: an external consultant or a competent employee outside the implementing team. The review covers the approach — policies, risk method, objectives — and whether implementation matches it. A certification auditor will expect an independent-review program, reports with real findings, and evidence findings were resolved; a review that finds nothing invites scrutiny.

  • An independent review or internal audit plan with scope, criteria and schedule
  • Reviewer independence documented — external party or staff outside the implementing team
  • Review reports with findings, presented to management with dates
  • Corrective actions from reviews tracked to closure in the ticket system

  ISO/IEC 27001:2022, A.5.35 — Independent review of information security — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.36: Compliance with policies, rules and standards for information security [ISO/IEC 27001 (information security management system): own-words representation; A.5.36]
  What's needed: Verify your own rules are followed before the auditor does: schedule periodic checks that practice matches policy — access reviews done on time, endpoints encrypted, branches protected, backups running — and record each check with its result. When a check finds a gap, raise a nonconformity, fix it, and note the cause. A certification auditor will expect a conformance-check calendar, the results, and the corrections made; all-clean results look unexamined.

  • A schedule of policy conformance checks with owner and frequency per area
  • Check results recorded with date, method and outcome, including technical scans
  • Nonconformity records with the correction and cause analysis
  • Management visibility of check outcomes, such as a recurring review summary

  ISO/IEC 27001:2022, A.5.36 — Compliance with policies, rules and standards for information security — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.37: Documented operating procedures [ISO/IEC 27001 (information security management system): own-words representation; A.5.37]
  What's needed: Write runbooks for the operations done under pressure or for the first time: deployment and rollback, backup and restore, key rotation, onboarding and offboarding, environment rebuild. Keep them versioned where operators work — wiki or repo — assign owners, and update them when the change that breaks them ships. A certification auditor will expect dated, current procedures, access for the people who run them, and signs of real use, like edits after changes.

  • Versioned runbooks for deploys, backup/restore, key rotation and offboarding, each with an owner
  • Change history showing procedures updated after system changes
  • Access records confirming operators can reach the procedures they use
  • A procedure exercised in practice, such as a restore performed from the runbook

  ISO/IEC 27001:2022, A.5.37 — Documented operating procedures — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.1: Screening [ISO/IEC 27001 (information security management system): own-words representation; A.6.1]
  What's needed: Run proportionate background checks before an offer becomes binding: identity, right to work, references, and — where a role touches production data or customer secrets — the deeper checks local law permits. Scale depth to role risk and record the outcome for each hire. An ISO 27001 certification auditor will expect to see screening defined in the hiring workflow and evidence it ran for recent joiners, including engineers with production access.

  • A screening standard defining check types by role risk, dated and approved
  • Completed screening records or vendor reports for recent hires, including engineering roles
  • HR checklist or ATS ticket showing checks closed before system access was granted
  • A re-screening trigger for moves into higher-risk roles, with one executed example

  ISO/IEC 27001:2022, A.6.1 — Screening — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.2: Terms and conditions of employment [ISO/IEC 27001 (information security management system): own-words representation; A.6.2]
  What's needed: Put security duties into the employment contract itself, not only a handbook: confidentiality, acceptable use, IP assignment, obligations that survive exit, and consequences of violation. Give contractors equivalent clauses. A certification auditor will expect to see the current template containing these terms, signed copies for a sample of staff, and proof the wording gets reviewed when policies change so new hires never sign an outdated set of duties.

  • Current employment contract template with security, confidentiality and IP clauses, versioned
  • Signed contracts on file for a sample of employees and equivalent terms for contractors
  • Review note showing contract wording checked after the last policy update
  • Onboarding checklist confirming terms are signed before first-day access

  ISO/IEC 27001:2022, A.6.2 — Terms and conditions of employment — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.3: Information security awareness, education and training [ISO/IEC 27001 (information security management system): own-words representation; A.6.3]
  What's needed: Stand up a training cycle matched to roles: security onboarding before access is granted, an annual refresher, and targeted content for engineers on secure coding and secrets handling. Track completion by name and chase stragglers. A certification auditor will expect to see the curriculum, completion records with dates, follow-up where people lapsed, and evidence the content itself gets refreshed when policies or the threat picture change.

  • Training curriculum mapped to roles, with an owner and last-review date
  • Completion records by person and date for onboarding and the annual refresher
  • Escalation trail for non-completers showing the gap was closed
  • Role-specific module for engineers covering secure coding and secrets handling
  • Change log showing content updated after a policy or threat change

  ISO/IEC 27001:2022, A.6.3 — Information security awareness, education and training — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.4: Disciplinary process [ISO/IEC 27001 (information security management system): own-words representation; A.6.4]
  What's needed: Write down what happens when someone violates a security policy: who investigates, the range of outcomes from coaching to dismissal, and how proportionality and fairness are safeguarded. Communicate it so staff know the consequences before any incident occurs. A certification auditor will expect to see the documented process, evidence personnel were told about it, and — where a violation has occurred — a record showing the process was genuinely followed.

  • A documented disciplinary process naming investigators, outcomes and fairness safeguards
  • Evidence of communication: handbook section, onboarding slide, or signed acknowledgement
  • A record of a handled violation showing the documented steps were followed
  • HR and security sign-off on the process, with a review date

  ISO/IEC 27001:2022, A.6.4 — Disciplinary process — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.5: Responsibilities after termination or change of employment [ISO/IEC 27001 (information security management system): own-words representation; A.6.5]
  What's needed: Define the duties that survive exit — confidentiality, return of assets, IP terms — and build them into offboarding: a leaver checklist that revokes access on the last day, recovers devices, and reminds the leaver in writing of continuing obligations. A certification auditor will expect to see the documented post-employment duties, completed checklists for recent departures, and access-revocation records that line up with each leaver's final day.

  • Documented post-employment duties covering confidentiality, assets and IP
  • Completed leaver checklists for recent departures with dates and sign-offs
  • Access-revocation logs matching each leaver's final day
  • Exit letter or email reminding the leaver of continuing obligations

  ISO/IEC 27001:2022, A.6.5 — Responsibilities after termination or change of employment — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.6: Confidentiality or non-disclosure agreements [ISO/IEC 27001 (information security management system): own-words representation; A.6.6]
  What's needed: Keep a standard confidentiality agreement, a register of who signed which version — employees, contractors, advisors, counterparties — and a periodic review so the terms still match what the company actually protects, including model IP and customer data. A certification auditor will expect to see the current template with its review history, signed agreements on file, and a working check that no third party receives sensitive material before signing.

  • Current NDA template reviewed on a stated cycle, with version history
  • Register of signed agreements across employees, contractors and advisors
  • Signed NDA predating any third party's receipt of sensitive material
  • Review note showing terms updated to cover model IP and customer data

  ISO/IEC 27001:2022, A.6.6 — Confidentiality or non-disclosure agreements — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.7: Remote working [ISO/IEC 27001 (information security management system): own-words representation; A.6.7]
  What's needed: Assume a remote-first reality and secure it deliberately: a remote-working policy covering screen privacy, home networks, company-managed devices, VPN or zero-trust access, and work in public spaces. Enforce the technical parts through endpoint management rather than trust. A certification auditor will expect to see the policy with staff acknowledgements, MDM enrolment across the fleet, and disk encryption verified on remote laptops.

  • Remote-working policy with staff acknowledgements on record
  • MDM console export showing enrolment and disk encryption across the laptop fleet
  • VPN or zero-trust access configuration enforcing device checks
  • Spot-check or internal review of remote-work controls with follow-ups closed

  ISO/IEC 27001:2022, A.6.7 — Remote working — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.8: Information security event reporting [ISO/IEC 27001 (information security management system): own-words representation; A.6.8]
  What's needed: Give people one obvious, low-friction way to report anything suspicious — a #security channel, an alias or a form — and make clear that near-misses and honest mistakes are welcome, not punished. Route reports into the incident process with triage timestamps. A certification auditor will expect to see the channel publicized in onboarding and policy, real reports with triage outcomes, and feedback to reporters that keeps the channel alive.

  • Reporting channel documented in policy and onboarding materials
  • Log of reported events with triage timestamps and outcomes
  • An example report followed through to closure with feedback to the reporter
  • Periodic reminder or awareness message keeping the channel visible

  ISO/IEC 27001:2022, A.6.8 — Information security event reporting — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.1: Physical security perimeters [ISO/IEC 27001 (information security management system): own-words representation; A.7.1]
  What's needed: Applies where the organization operates its own premises or processing facilities; a cloud-only startup typically inherits data-centre perimeters through its provider's controls. Where you keep an office or server room, define the perimeter — locked doors, reception — around spaces holding sensitive equipment or records. Record that scoping decision and the reason in your Statement of Applicability, and confirm the boundary with your certification auditor.

  • SoA entry recording the perimeter scoping decision and its rationale
  • Provider assurance report (e.g. SOC 2 or ISO certificate) covering data-centre perimeters
  • Floor plan or description marking perimeter boundaries for any office or server room
  • Lease or building documentation showing perimeter measures inherited from the landlord

  ISO/IEC 27001:2022, A.7.1 — Physical security perimeters — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.2: Physical entry [ISO/IEC 27001 (information security management system): own-words representation; A.7.2]
  What's needed: Applies where the organization controls entry to premises of its own; serviced-office tenants often inherit entry controls from the building operator. Where you run your own space, use badge or key access with an issuance register, visitor sign-in with escorts, and prompt revocation when people leave. Record that scoping decision and the reason in your Statement of Applicability, and confirm the boundary with your certification auditor.

  • Badge or key issuance register reconciled to current staff
  • Visitor log with sign-in, escort and sign-out entries
  • Entry-credential revocation records for recent leavers
  • SoA entry documenting inherited building entry controls and the rationale

  ISO/IEC 27001:2022, A.7.2 — Physical entry — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.3: Securing offices, rooms and facilities [ISO/IEC 27001 (information security management system): own-words representation; A.7.3]
  What's needed: Applies where the organization occupies offices or rooms it must secure itself; a fully remote company may hold no such facilities. Where an office exists, keep exterior signage minimal, lock rooms holding equipment or records, and keep sensitive work out of public sightlines. Record that scoping decision and the reason in your Statement of Applicability, and confirm the boundary with your certification auditor.

  • SoA entry recording the office-security scoping decision and its rationale
  • Photos or walkthrough notes showing locked rooms for equipment and records
  • Key or code inventory for secured rooms, with holders named

  ISO/IEC 27001:2022, A.7.3 — Securing offices, rooms and facilities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.4: Physical security monitoring [ISO/IEC 27001 (information security management system): own-words representation; A.7.4]
  What's needed: Applies where the organization operates premises it must watch for intrusion; serviced offices and provider data centres usually furnish monitoring through building alarms and CCTV. Where you run your own space, alarm the entry points, review alerts and act on them, and respect local privacy law on surveillance. Record that scoping decision and the reason in your Statement of Applicability, and confirm the boundary with your certification auditor.

  • Alarm or CCTV coverage description for entry points, or the building operator's monitoring terms
  • Log of monitoring alerts with review outcomes
  • Surveillance notice and retention setting aligned to local privacy law
  • SoA entry recording the monitoring scoping decision and its rationale

  ISO/IEC 27001:2022, A.7.4 — Physical security monitoring — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.5: Protecting against physical and environmental threats [ISO/IEC 27001 (information security management system): own-words representation; A.7.5]
  What's needed: Applies where the organization operates facilities exposed to fire, flood or similar hazards; for hosted workloads these protections sit with the cloud provider and are checked via its assurance reports. For any office you keep, cover the basics: fire detection, sensible siting of equipment, and insurance against physical loss. Record that scoping decision and the reason in your Statement of Applicability, and confirm the boundary with your certification auditor.

  • Provider assurance report covering environmental protections for hosted infrastructure
  • Fire detection and suppression details for any occupied office
  • SoA entry recording the environmental-threat scoping decision and its rationale
  • Insurance schedule or risk note covering physical hazards to equipment

  ISO/IEC 27001:2022, A.7.5 — Protecting against physical and environmental threats — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.6: Working in secure areas [ISO/IEC 27001 (information security management system): own-words representation; A.7.6]
  What's needed: Applies where the organization maintains designated secure areas; most small SaaS teams have none and rely on their provider's data-centre practices. Where such areas exist, set rules for working inside them: supervision, no unattended visitors, limits on phones and cameras, and discretion about what is seen. Record that scoping decision and the reason in your Statement of Applicability, and confirm the boundary with your certification auditor.

  • SoA entry recording whether designated secure areas exist, with the rationale
  • Secure-area working rules covering supervision, devices and confidentiality
  • Sign-in or authorization records for work performed in a secure area

  ISO/IEC 27001:2022, A.7.6 — Working in secure areas — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.7: Clear desk and clear screen [ISO/IEC 27001 (information security management system): own-words representation; A.7.7]
  What's needed: Even a cloud-only startup has laptops, screens and the occasional printout, so set simple rules: short automatic screen-lock timeouts, locking devices when stepping away, no credentials on paper, and shredding or secure bins for sensitive documents. Enforce the technical half centrally through endpoint policy. A certification auditor will expect to see the rule in policy, lock settings pushed by MDM, and spot-check results with follow-ups closed.

  • Endpoint policy export showing enforced screen-lock timeout across the fleet
  • Clear desk and clear screen rule in the security policy with acknowledgements
  • Walkthrough or spot-check record with findings and follow-ups
  • Shredder or secure disposal arrangement for sensitive paper

  ISO/IEC 27001:2022, A.7.7 — Clear desk and clear screen — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.8: Equipment siting and protection [ISO/IEC 27001 (information security management system): own-words representation; A.7.8]
  What's needed: Applies where the organization sites equipment of its own — servers, network gear or shared office hardware beyond individual laptops. Where it does, place gear in locked cabinets, position screens away from public view, and keep equipment clear of water, heat and theft risks. Record that scoping decision and the reason in your Statement of Applicability, and confirm the boundary with your certification auditor.

  • SoA entry recording the equipment-siting scoping decision and its rationale
  • Locked cabinet or room for network gear, evidenced by photo or walkthrough note
  • Office layout note showing screens angled away from public sightlines

  ISO/IEC 27001:2022, A.7.8 — Equipment siting and protection — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.9: Security of assets off-premises [ISO/IEC 27001 (information security management system): own-words representation; A.7.9]
  What's needed: Treat every laptop that leaves a desk — for a startup, all of them — as an off-premises asset: full-disk encryption, remote wipe, an asset register showing who holds what, and rules for travel and public networks. Loss or theft feeds straight into the incident process. A certification auditor will expect to see the register reconciled to people, encryption and wipe capability verified from the MDM console, and a handled loss report or a tested drill.

  • Asset register listing devices, holders and locations, reconciled on a stated cycle
  • MDM export verifying encryption and remote-wipe capability on laptops
  • Travel and public-network rules in the remote or acceptable-use policy
  • A device-loss report handled through the incident process, or a tested wipe drill

  ISO/IEC 27001:2022, A.7.9 — Security of assets off-premises — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.10: Storage media [ISO/IEC 27001 (information security management system): own-words representation; A.7.10]
  What's needed: Manage the full life of any media you touch — laptop drives, USB sticks, backup media — from purchase through use, transfer and destruction, in line with the data classification scheme. Many startups simply block removable USB storage via endpoint policy, and that restriction is itself the control. A certification auditor will expect to see media rules in policy, technical enforcement of the USB stance, and wipe or destruction records for retired drives.

  • Media handling rules tied to the data classification scheme
  • Endpoint configuration blocking or restricting removable USB storage
  • Wipe or destruction records for retired drives and media
  • Chain-of-custody note for any media physically transferred

  ISO/IEC 27001:2022, A.7.10 — Storage media — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.11: Supporting utilities [ISO/IEC 27001 (information security management system): own-words representation; A.7.11]
  What's needed: Applies where the organization runs facilities that depend on power, cooling or connectivity it must protect; for cloud infrastructure this duty sits with the hosting provider and is verified through its assurance reports. For an office, a UPS on network gear and a backup internet path cover the pragmatic layer. Record that scoping decision and the reason in your Statement of Applicability, and confirm the boundary with your certification auditor.

  • SoA entry recording the supporting-utilities scoping decision and its rationale
  • Provider assurance report covering power and cooling for hosted infrastructure
  • UPS or failover arrangement for office network equipment
  • Internet redundancy or outage plan where connectivity loss hurts operations

  ISO/IEC 27001:2022, A.7.11 — Supporting utilities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.12: Cabling security [ISO/IEC 27001 (information security management system): own-words representation; A.7.12]
  What's needed: Applies where the organization installs or manages its own power or network cabling; co-working tenants and cloud-only teams rarely do. Where you do run cabling, route it away from public access, label both ends, and lock patch panels and risers so tampering is evident. Record that scoping decision and the reason in your Statement of Applicability, and confirm the boundary with your certification auditor.

  • SoA entry recording the cabling scoping decision and its rationale
  • Photos or notes showing protected, labelled cabling and locked patch panels
  • Building or provider terms covering cabling protection where inherited

  ISO/IEC 27001:2022, A.7.12 — Cabling security — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.13: Equipment maintenance [ISO/IEC 27001 (information security management system): own-words representation; A.7.13]
  What's needed: For a laptop fleet, maintenance means keeping hardware healthy without exposing data: OS and firmware updates pushed through MDM, disk and battery health watched, and repairs routed through channels where the encrypted disk stays encrypted or is removed first. A certification auditor will expect to see patch status reported per device, a repair procedure that addresses data on serviced machines, and maintenance entries on the asset register.

  • MDM report showing patch and firmware status per device
  • Repair procedure addressing data protection on serviced machines
  • Maintenance entries on the asset register with dates and outcomes
  • Warranty or vendor service records for repaired equipment

  ISO/IEC 27001:2022, A.7.13 — Equipment maintenance — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.14: Secure disposal or re-use of equipment [ISO/IEC 27001 (information security management system): own-words representation; A.7.14]
  What's needed: Before a laptop or drive is sold, recycled, returned or handed to a new joiner, verify the data is gone: cryptographic erase or full overwrite, plus removal of accounts and licensed software. Keep proof per device — 'we think it was wiped' fails an audit. A certification auditor will expect to see a disposal procedure, wipe or destruction records tied to serial numbers in the asset register, and vendor destruction certificates where disposal is outsourced.

  • Disposal and re-use procedure specifying the wipe method per media type
  • Wipe or destruction record tied to each device serial in the asset register
  • Vendor destruction certificates where disposal is outsourced
  • Pre-reissue checklist confirming accounts and licensed software removed

  ISO/IEC 27001:2022, A.7.14 — Secure disposal or re-use of equipment — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.1: User endpoint devices [ISO/IEC 27001 (information security management system): own-words representation; A.8.1]
  What's needed: For a small SaaS startup this means enrolling every laptop that touches company data in an MDM or endpoint-management tool that enforces full-disk encryption, screen lock, OS auto-update and remote wipe, backed by an endpoint policy covering any personal-device use. A certification auditor will expect to see the enforced configuration and a device inventory reconciled to the current staff list, not just a written rule nobody checks against reality.

  • Endpoint policy, dated and approved, covering laptops, mobiles and any personal-device use
  • MDM console export showing enrolled devices with disk encryption and screen lock enforced
  • Device inventory reconciled against the current staff list, with a dated review
  • Record of a remote wipe or lock action taken for a lost or offboarded device

  ISO/IEC 27001:2022, A.8.1 — User endpoint devices — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.2: Privileged access rights [ISO/IEC 27001 (information security management system): own-words representation; A.8.2]
  What's needed: Keep admin rights rare, individual and time-bound: separate admin accounts from daily-use identities, grant cloud and production privileges only through a recorded approval, and review the privileged list on a schedule. A certification auditor will expect to see who holds elevated rights in each system, the approval behind each grant, and evidence that reviews actually remove access — a stale admin account left on the list is the classic finding.

  • Register of privileged accounts per system, mapped to named individuals
  • Approval tickets for each privileged-access grant, stating the business reason
  • Dated privileged-access review with revocations actioned and closed
  • Configuration showing separate admin identities or just-in-time elevation for production

  ISO/IEC 27001:2022, A.8.2 — Privileged access rights — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.3: Information access restriction [ISO/IEC 27001 (information security management system): own-words representation; A.8.3]
  What's needed: Enforce the access-control rules inside the systems themselves: role-based permissions in the cloud console, database and SaaS tools, restricted views over sensitive records, and deny-by-default sharing. A certification auditor will expect to see the mapping from your access-control policy to actual configuration — a permissions export showing who can reach what — plus a recurring access review that catches and corrects drift rather than rubber-stamping it.

  • Permissions export from key systems showing role-based access aligned to job function
  • Dated user-access review with discrepancies logged and corrected
  • Configuration showing deny-by-default sharing on repositories and document stores
  • Ticket trail for an access-change request from approval through implementation

  ISO/IEC 27001:2022, A.8.3 — Information access restriction — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.4: Access to source code [ISO/IEC 27001 (information security management system): own-words representation; A.8.4]
  What's needed: Treat the code platform as a controlled asset: private repositories, membership tied to joiner-mover-leaver, branch protection so changes reach main only through reviewed pull requests, and tightly held rights over CI/CD secrets and package registries. A certification auditor will expect to see repository permission exports, the protected-branch settings, and evidence that a leaver's code access was revoked promptly — the offboarding record is the proof point.

  • Repository access export showing members, roles and the last review date
  • Branch-protection settings requiring review before merge to protected branches
  • Offboarding record showing code-platform access revoked on exit
  • Access restrictions over CI/CD pipelines, secrets and internal package registries

  ISO/IEC 27001:2022, A.8.4 — Access to source code — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.5: Secure authentication [ISO/IEC 27001 (information security management system): own-words representation; A.8.5]
  What's needed: Make strong authentication the default path: SSO where tools support it, MFA enforced for all staff on email, the code platform, the cloud console and production, and secrets or API keys handled through a vault instead of shared passwords. A certification auditor will expect to see the enforcement settings — an MFA policy export, conditional-access or SSO configuration — plus a password standard and evidence that any exceptions are known, justified and time-limited.

  • Identity-provider export showing MFA enforced for all users, exceptions listed and justified
  • SSO configuration covering the core business and production systems
  • Password and secrets-handling standard, dated and approved
  • Lockout or login-throttling settings evidencing brute-force protection

  ISO/IEC 27001:2022, A.8.5 — Secure authentication — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.6: Capacity management [ISO/IEC 27001 (information security management system): own-words representation; A.8.6]
  What's needed: In a cloud stack this is mostly monitoring plus headroom decisions: track compute, storage, database and third-party API-quota utilization against expected growth, set alert thresholds that fire before hard limits bite, and use autoscaling or scheduled reviews to adjust. A certification auditor will expect to see dashboards and alerts wired to real thresholds, and a record of a capacity decision — a scale-up, quota increase or cost trade-off — actually taken.

  • Monitoring dashboards covering compute, storage, database and third-party API quotas
  • Alert configuration with thresholds set below hard limits
  • Record of a capacity action taken in response to a trend or alert
  • Periodic capacity review notes considering forecast growth

  ISO/IEC 27001:2022, A.8.6 — Capacity management — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.7: Protection against malware [ISO/IEC 27001 (information security management system): own-words representation; A.8.7]
  What's needed: Layer technical controls with awareness: endpoint protection actively managed on every laptop, restrictions on running unvetted software, malware scanning where files enter your platform, and phishing and malware content inside security training. A certification auditor will expect to see central visibility that protection is on and current across the fleet, plus what actually happened when something was detected or a user reported a suspicious file.

  • Endpoint-protection console showing coverage and engine currency across all devices
  • Rule restricting installation of unauthorized software, with its enforcement mechanism
  • Training records covering malware and phishing awareness
  • Record of a detection or reported suspicious file and the follow-up taken

  ISO/IEC 27001:2022, A.8.7 — Protection against malware — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.8: Management of technical vulnerabilities [ISO/IEC 27001 (information security management system): own-words representation; A.8.8]
  What's needed: Run a pipeline, not an annual scramble: dependency and container scanning in CI, cloud-provider and vendor advisories feeding a triage queue, remediation timelines by severity, and periodic external scans or a penetration test. A certification auditor will expect to see scanner output tied to tickets, closure within your stated timelines, and a documented risk-based decision for anything you chose not to fix immediately — silent aging findings are what fails here.

  • Dependency and container scan reports from CI with dates and findings
  • Vulnerability tickets showing triage severity and closure within the stated timeline
  • Approved remediation-timeline standard by severity, versioned
  • Latest penetration test or external scan report with tracked follow-ups

  ISO/IEC 27001:2022, A.8.8 — Management of technical vulnerabilities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.9: Configuration management [ISO/IEC 27001 (information security management system): own-words representation; A.8.9]
  What's needed: Define secure baselines and keep them enforced: infrastructure-as-code for cloud resources, hardened defaults — no public buckets, least-privilege security groups, TLS everywhere — and drift detection so manual console edits surface quickly. A certification auditor will expect to see the baseline written down, the tooling that enforces or checks it, and a record of a misconfiguration that was detected and corrected, which is the evidence the loop actually runs.

  • Documented secure-configuration baselines for cloud services, OS images and key SaaS tools
  • Infrastructure-as-code repository with reviewed changes as the route to production config
  • Drift-detection or cloud-posture tool output with findings and fixes
  • Change record showing a configuration deviation corrected

  ISO/IEC 27001:2022, A.8.9 — Configuration management — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.10: Information deletion [ISO/IEC 27001 (information security management system): own-words representation; A.8.10]
  What's needed: Tie deletion to defined retention: state how long each data category lives, implement automated expiry where the platform supports it — log retention, backup aging, object-lifecycle rules — and honor contractual and legal deletion duties including data-subject requests. A certification auditor will expect to see the retention rules in writing, the technical settings that execute them, and a completed deletion — a request or a scheduled purge — with proof it ran.

  • Retention schedule per data category, dated and approved
  • Lifecycle and expiry configuration in storage, logging and backup systems
  • Completed deletion request with confirmation and timestamp
  • Sanitization or account-closure records for decommissioned systems and devices

  ISO/IEC 27001:2022, A.8.10 — Information deletion — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.11: Data masking [ISO/IEC 27001 (information security management system): own-words representation; A.8.11]
  What's needed: Decide where real personal or sensitive data is genuinely needed and mask everywhere else: pseudonymized or synthetic data in dev, test and demos, redaction of secrets and PII in logs and error trackers, and masked views where support staff work. A certification auditor will expect to see the rule — which fields, which technique, which environments — and technical proof such as a sampled log line or test dataset showing masked values, not a bare policy statement.

  • Masking and pseudonymization standard naming fields, techniques and environments
  • Sanitized or synthetic test dataset used in non-production environments
  • Log-scrubbing configuration with a sample showing PII and secrets redacted
  • Access design showing masked views for support or analytics roles

  ISO/IEC 27001:2022, A.8.11 — Data masking — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.12: Data leakage prevention [ISO/IEC 27001 (information security management system): own-words representation; A.8.12]
  What's needed: For a startup this is targeted, not an enterprise suite: identify where sensitive data could exit — email, cloud sharing, repositories, external AI tools, endpoints — then set controls: sharing restrictions, secret-scanning on commits, egress rules, and clear guidance on pasting customer data into outside services. A certification auditor will expect to see that exit-path analysis, the enforced settings, and how an attempted leak would be spotted and handled.

  • Documented assessment of data-exfiltration paths and the control chosen for each
  • Secret-scanning enabled on repositories with an example alert resolved
  • Sharing restrictions configured in email and collaboration tools
  • Rule on use of external AI and file-sharing services, with acknowledgement records

  ISO/IEC 27001:2022, A.8.12 — Data leakage prevention — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.13: Information backup [ISO/IEC 27001 (information security management system): own-words representation; A.8.13]
  What's needed: Back up what the business must be able to recover — production databases, object storage, configuration and code — on a defined schedule, protect copies from the very account that could be compromised (separate credentials or immutability), and restore-test regularly. A certification auditor will expect a backup policy stating coverage, frequency and retention, evidence the jobs succeed, and a dated restore test with its outcome; untested backups convince no one.

  • Backup policy defining coverage, frequency, retention and encryption, dated and approved
  • Backup job logs or console evidence showing successful recent runs
  • Dated restore-test record with the result and time-to-recover measured
  • Configuration showing backups isolated from production credentials or made immutable

  ISO/IEC 27001:2022, A.8.13 — Information backup — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.14: Redundancy of information processing facilities [ISO/IEC 27001 (information security management system): own-words representation; A.8.14]
  What's needed: Match redundancy to your availability commitments: multi-AZ databases and stateless services behind load balancing, health checks with automatic replacement, and a documented view of the single points of failure you knowingly accept. A certification auditor will expect to see the availability targets, the architecture that meets them, and evidence of behavior under failure — a failover exercise, an availability-zone event weathered, or a replica promotion tested.

  • Documented availability targets and the service commitments made to customers
  • Architecture diagram showing multi-AZ or replicated deployment of critical components
  • Failover or replica-promotion test record with the observed outcome
  • Analysis of single points of failure with accepted-risk decisions recorded

  ISO/IEC 27001:2022, A.8.14 — Redundancy of information processing facilities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.15: Logging [ISO/IEC 27001 (information security management system): own-words representation; A.8.15]
  What's needed: Centralize logs from applications, the cloud control plane, the identity provider and databases into one searchable store with a set retention, protect them from tampering by the very people they cover, and actually look at them. A certification auditor will expect to see the log sources enumerated, access to the store restricted and itself logged, retention matching your stated policy, and an example of a log-driven review or investigation with its outcome.

  • Inventory of log sources feeding the central store, with retention periods
  • Access controls on the logging platform restricting modification and deletion
  • Cloud control-plane audit logging enabled across all accounts
  • Record of a log review or investigation with findings and actions

  ISO/IEC 27001:2022, A.8.15 — Logging — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.16: Monitoring activities [ISO/IEC 27001 (information security management system): own-words representation; A.8.16]
  What's needed: Define what abnormal looks like for your stack and alert on it: authentication anomalies, cloud control-plane changes, error and traffic spikes, new privileged grants, security-tool findings. Route alerts to people who respond, and tune the noise so a page means something. A certification auditor will expect to see the alert rules, where they go, and one handled alert end-to-end — detection, triage, decision — feeding the incident process when it turns out real.

  • Alert rules covering authentication, control-plane and application anomalies
  • On-call or alert-routing configuration naming the responsible responders
  • A triaged alert record showing detection through decision
  • Periodic tuning review reducing false positives, with the changes noted

  ISO/IEC 27001:2022, A.8.16 — Monitoring activities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.17: Clock synchronization [ISO/IEC 27001 (information security management system): own-words representation; A.8.17]
  What's needed: Largely inherited in the cloud: managed services already sync to the provider's time source, so evidence it rather than rebuild it — confirm NTP on any VMs or containers you run yourself, standardize on UTC timestamps across logs, and enroll laptops in OS time sync. A certification auditor will expect to see the approved time-source decision written down and consistent timestamps across systems, because incident timelines fall apart when clocks disagree.

  • Documented time-source standard naming the approved references and UTC convention
  • Configuration showing NTP enabled on self-managed hosts and containers
  • Log samples from separate systems with consistent UTC timestamps
  • MDM or OS policy enforcing time synchronization on endpoints

  ISO/IEC 27001:2022, A.8.17 — Clock synchronization — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.18: Use of privileged utility programs [ISO/IEC 27001 (information security management system): own-words representation; A.8.18]
  What's needed: In a cloud stack the dangerous utilities are database consoles, cloud-provider root sessions, kubectl exec and debugging tools that bypass the product's own controls. Keep them behind SSO and role membership, grant use just-in-time with an expiry, and log every session. A certification auditor will expect to see the short list of who can run them, the approval trail for each grant, and session logs that reconcile against that list.

  • A documented list of privileged utilities and the roles permitted to run them, dated and reviewed
  • Just-in-time access grants with requester, approver and expiry recorded
  • Session logs from database consoles and cloud shell access tied to named users
  • A quarterly review reconciling actual utility use against the permitted list

  ISO/IEC 27001:2022, A.8.18 — Use of privileged utility programs — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.19: Installation of software on operational systems [ISO/IEC 27001 (information security management system): own-words representation; A.8.19]
  What's needed: For a SaaS startup the honest control is that the CI/CD pipeline is the only way software reaches production: immutable images built from reviewed code, no SSH package installs on live hosts, and dependency versions pinned and scanned. A certification auditor will expect to see the deployment procedure, evidence that direct installs are blocked or at least alerted on, and a rollback path proven at least once.

  • A deployment procedure naming the pipeline as the only install path to production
  • Pipeline configuration building from reviewed, tagged source with pinned dependencies
  • Alerts or host controls covering manual package installs on production instances
  • A rollback record showing a prior version was restored successfully

  ISO/IEC 27001:2022, A.8.19 — Installation of software on operational systems — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.20: Networks security [ISO/IEC 27001 (information security management system): own-words representation; A.8.20]
  What's needed: Even on cloud infrastructure you own the network design: private subnets for data stores, deny-by-default security groups, TLS on every hop, and flow logs feeding your monitoring. Keep a current network diagram and review firewall rules on a schedule. A certification auditor will expect to see the diagram matching deployed reality, the rule-review records with changes ticketed, and alerts wired to unexpected traffic.

  • A current network diagram showing subnets, security groups and data-store placement
  • Deny-by-default firewall or security-group rules exported from the cloud console
  • Scheduled rule-review records with changes ticketed and closed
  • VPC flow logs or equivalent feeding alerts, with a sample investigated event

  ISO/IEC 27001:2022, A.8.20 — Networks security — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.21: Security of network services [ISO/IEC 27001 (information security management system): own-words representation; A.8.21]
  What's needed: List every network service you consume — cloud VPC and load balancers, CDN, DNS, VPN, email — and record for each the security mechanisms you rely on and the service levels promised. Then monitor that they hold: uptime checks, TLS configuration scans, provider status alerts. A certification auditor will expect to see that inventory, the agreements behind it, and monitoring output showing the mechanisms actually work.

  • An inventory of network services with the security mechanisms and service levels relied on
  • Agreements or provider terms documenting those commitments
  • Monitoring dashboards or checks covering uptime and TLS configuration
  • A record of a service-level deviation raised with the provider and tracked

  ISO/IEC 27001:2022, A.8.21 — Security of network services — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.22: Segregation of networks [ISO/IEC 27001 (information security management system): own-words representation; A.8.22]
  What's needed: Segregate by trust level: production isolated from development in separate cloud accounts or VPCs, AI workloads and data stores in private subnets, corporate endpoints never routed into production, and cross-boundary paths explicit and deny-by-default. A certification auditor will expect to see the segmentation design, the account and VPC structure that enforces it, and rules showing the boundaries are closed rather than merely drawn.

  • A segmentation design showing environments and trust zones in separate accounts or VPCs
  • Security-group and routing rules showing deny-by-default between zones
  • Evidence corporate endpoints have no direct route into production networks
  • A periodic review confirming cross-zone rules still match the design

  ISO/IEC 27001:2022, A.8.22 — Segregation of networks — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.23: Web filtering [ISO/IEC 27001 (information security management system): own-words representation; A.8.23]
  What's needed: For a small team this is usually DNS-level filtering pushed through endpoint management: block known-malicious domains, phishing infrastructure and any categories you have chosen to bar, on every company device including remote ones. Write down what is blocked and who can approve exceptions. A certification auditor will expect to see the filtering configuration, the blocklist rationale, and logs showing blocked attempts actually occur.

  • DNS or web-filtering configuration deployed to all managed endpoints
  • A written list of blocked categories with the rationale and exception process
  • Filter logs showing malicious or barred requests being blocked
  • Exception approvals with requester, approver and expiry

  ISO/IEC 27001:2022, A.8.23 — Web filtering — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.24: Use of cryptography [ISO/IEC 27001 (information security management system): own-words representation; A.8.24]
  What's needed: Write a short cryptography standard: approved algorithms and TLS versions, encryption at rest and in transit by default, and keys held in a cloud KMS with rotation, access control and no keys in code or config. Cover customer data, model artifacts and backups alike. A certification auditor will expect to see the standard, a KMS key inventory with rotation evidence, and scans confirming weak protocols are disabled.

  • A cryptography standard naming approved algorithms, TLS versions and key-handling rules
  • A KMS key inventory with owners, purpose and rotation dates
  • Configuration or scan output confirming encryption at rest and in transit is enforced
  • Secret-scanning results showing no keys committed to source control

  ISO/IEC 27001:2022, A.8.24 — Use of cryptography — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.25: Secure development life cycle [ISO/IEC 27001 (information security management system): own-words representation; A.8.25]
  What's needed: Define your secure development rules once and make the pipeline enforce them: protected branches, mandatory peer review, security checks in CI, secrets scanning, and a definition of done that includes security. The rules should cover AI components — prompts, models, training code — not only product code. A certification auditor will expect to see the written SDLC standard, branch-protection settings matching it, and merged changes that visibly passed the gates.

  • A written secure development standard covering review, testing and secrets handling
  • Branch-protection and CI settings matching the standard
  • A sampled merge showing peer review and security checks passed before deploy
  • A record of the standard being updated after an incident or a new AI component

  ISO/IEC 27001:2022, A.8.25 — Secure development life cycle — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.26: Application security requirements [ISO/IEC 27001 (information security management system): own-words representation; A.8.26]
  What's needed: Capture security requirements before you build or buy: for each new feature or acquired tool, record what data it touches, the authentication, authorization, logging and encryption it must provide, and who approved that list. Lightweight works — a security section in the design doc or ticket template. A certification auditor will expect to see requirements recorded ahead of the build, approval by a named owner, and traceability into the delivered change.

  • A design-doc or ticket template with a security requirements section
  • Recorded requirements for a recent feature, approved by a named owner before build
  • A vendor or tool acquisition with its security requirements assessed and signed off
  • Traceability from stated requirements to the delivered change and its tests

  ISO/IEC 27001:2022, A.8.26 — Application security requirements — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.27: Secure system architecture and engineering principles [ISO/IEC 27001 (information security management system): own-words representation; A.8.27]
  What's needed: Document the engineering principles your systems are built on — least privilege, defense in depth, fail secure, no trust in client input, tenant isolation for a multi-tenant SaaS — and make design reviews check against them. Revisit the list when the architecture shifts, such as adding a model-serving tier. A certification auditor will expect to see the written principles, dated design reviews referencing them, and a record showing they shaped real decisions.

  • A documented set of secure engineering principles, versioned and owned
  • Design or architecture review records referencing the principles
  • An architecture decision record showing a principle shaped a real choice
  • Evidence the principles were revisited when the architecture changed

  ISO/IEC 27001:2022, A.8.27 — Secure system architecture and engineering principles — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.28: Secure coding [ISO/IEC 27001 (information security management system): own-words representation; A.8.28]
  What's needed: Adopt a secure coding standard your team actually uses: input validation, output encoding, parameterized queries, safe secrets handling, and rules for AI-specific hazards like prompt injection and unsafe deserialization of model files. Enforce it with linters and SAST in CI plus review checklists. A certification auditor will expect to see the standard, the pipeline gates that back it, and findings being fixed rather than silenced.

  • A secure coding standard covering common flaws and AI-specific hazards
  • Linter and SAST gates in CI configuration enforcing the standard
  • Review checklists or PR templates referencing secure coding items
  • Triage records showing findings fixed, with suppressions justified

  ISO/IEC 27001:2022, A.8.28 — Secure coding — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.29: Security testing in development and acceptance [ISO/IEC 27001 (information security management system): own-words representation; A.8.29]
  What's needed: Test security continuously, not once: SAST and dependency scanning on every merge, DAST or API security tests against staging, and acceptance criteria that block release on critical findings. Add a periodic penetration test as customer commitments grow. A certification auditor will expect to see the testing schedule, scan output tied to builds, triage records with fixes, and a pen-test report with remediation tracked to closure.

  • CI configuration running SAST and dependency scans on every merge
  • DAST or API security test results against a staging environment
  • Release criteria showing critical findings block deployment
  • A penetration test report with remediation tracked to closure

  ISO/IEC 27001:2022, A.8.29 — Security testing in development and acceptance — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.30: Outsourced development [ISO/IEC 27001 (information security management system): own-words representation; A.8.30]
  What's needed: When contractors or an agency write code, keep direction and review in-house: contracts carrying your security requirements, contributor access scoped and time-limited, all deliverables entering through your reviewed pipeline, and no outsourced path straight to production. A certification auditor will expect to see the contract clauses, review records on external contributions, and access logs showing outsiders never held standing production rights.

  • Contracts with external developers carrying your security and IP clauses
  • Scoped, time-limited access grants for external contributors
  • Review records on outsourced deliverables before merge
  • Access logs confirming no standing production rights for outsiders

  ISO/IEC 27001:2022, A.8.30 — Outsourced development — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.31: Separation of development, test and production environments [ISO/IEC 27001 (information security management system): own-words representation; A.8.31]
  What's needed: Run development, testing and production in separate cloud accounts or projects with separate credentials, separate secrets and no shared databases. Promotion happens only through the pipeline, and production data does not flow back into lower environments unprotected. A certification auditor will expect to see the account structure, IAM policies showing developers lack standing production write access, and the promotion path in the pipeline configuration.

  • Separate cloud accounts or projects for development, test and production
  • IAM policies showing developers lack standing production write access
  • Pipeline configuration as the only promotion path between environments
  • Distinct secrets and credentials per environment, with no reuse

  ISO/IEC 27001:2022, A.8.31 — Separation of development, test and production environments — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.32: Change management [ISO/IEC 27001 (information security management system): own-words representation; A.8.32]
  What's needed: Make the pull request your change record: every change to systems or infrastructure goes through review, automated checks and an approval before deploy, with infrastructure managed as code so it follows the same path. Define an emergency route that still logs and gets reviewed after the fact. A certification auditor will expect to see the procedure, a sampled change traced end to end, and an emergency change with its retrospective approval.

  • A change-management procedure covering normal and emergency changes
  • A sampled change traced from ticket through review, checks and deploy
  • Infrastructure-as-code history showing infrastructure changes follow the same path
  • An emergency change with its after-the-fact review and approval recorded

  ISO/IEC 27001:2022, A.8.32 — Change management — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.33: Test information [ISO/IEC 27001 (information security management system): own-words representation; A.8.33]
  What's needed: Decide deliberately what data may be used in test and model evaluation: default to synthetic or anonymized sets, and where production data is unavoidable, mask it, minimize it, approve the exception and delete it afterwards. For an AI product this covers evaluation and fine-tuning corpora too. A certification auditor will expect to see the test-data rules, the anonymization step in the pipeline, and approval records for any production-data exception.

  • Written rules for selecting and protecting test and evaluation data
  • An anonymization or synthetic-data step visible in the test pipeline
  • Approval records for any production-data exception, with deletion evidenced
  • Access controls on evaluation and fine-tuning datasets

  ISO/IEC 27001:2022, A.8.33 — Test information — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.34: Protection of information systems during audit testing [ISO/IEC 27001 (information security management system): own-words representation; A.8.34]
  What's needed: Plan assurance activities that touch live systems — penetration tests, auditor queries, customer security tests — before they run: agree scope, timing windows, accounts used and data limits with management, prefer read-only access, and point them at staging where feasible. A certification auditor will expect to see the signed rules of engagement, the approval for each exercise, and monitoring showing the activity stayed within the agreed bounds.

  • Signed rules of engagement for tests touching operational systems
  • Management approval recording scope, timing and account limits
  • Monitoring or logs showing activity stayed within the agreed window
  • A post-exercise review noting impact and any deviations

  ISO/IEC 27001:2022, A.8.34 — Protection of information systems during audit testing — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.

Requirements paraphrased in our own words and mapped to ISO/IEC 27001:2022 clause numbering. Not the standard itself — obtain ISO/IEC 27001 from ISO for the authoritative text. DRAFT pending internal review.

61 criteria (security, availability, confidentiality, processingIntegrity, privacy)

• CC1.1: Integrity and ethical values [SOC 2 Trust Services Criteria: own-words representation; CC1.1]
  What's needed: This is a management action, not a software task: the control environment rests on how leadership actually behaves, which no tool sets. A CPA auditor will expect to see a written code of conduct that binds staff and contractors, evidence people were told about it and acknowledged it, and a record of how suspected departures are investigated and corrected. What makes it real is the correction, not the document — show a case that was followed through.

  • A dated code of conduct or ethics policy covering employees and contractors, with a version history
  • Signed acknowledgements showing personnel received and accepted the standards of conduct
  • A record of a reported conduct concern with the investigation and the corrective action taken
  • Board or management minutes showing the standards are reinforced and reviewed periodically

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC1.1 — Integrity and ethical values — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC1.2: Governance and board oversight [SOC 2 Trust Services Criteria: own-words representation; CC1.2]
  What's needed: This is a management action, not a software task: independent, informed oversight is exercised by people, not produced by a platform. A CPA auditor will expect to see who provides governance oversight — a board, an advisory body, or a designated owner where no board exists — evidence they are sufficiently independent of day-to-day management, and a record that they actually reviewed security and internal-control performance, not just that the role exists on paper.

  • A charter or terms of reference defining the oversight body's responsibilities and independence
  • Minutes showing security and internal-control matters were reviewed at a defined cadence
  • A record of the relevant expertise the oversight members bring to that review
  • Evidence of a decision or follow-up the oversight body drove, showing the review has teeth

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC1.2 — Governance and board oversight — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC1.3: Organizational structure, authorities and responsibilities [SOC 2 Trust Services Criteria: own-words representation; CC1.3]
  What's needed: Set out who is responsible for what across the organization and keep it current as the business changes, so control duties have named owners rather than falling through the gaps. A CPA auditor will expect a picture of the reporting lines and the authorities that go with each role, and clear ownership of the internal-control and security responsibilities the system depends on. Show that it was updated when the organization changed shape.

  • A current organization chart with reporting lines and defined areas of authority
  • A responsibility matrix mapping key security and internal-control duties to named roles
  • Role descriptions or a RACI that state each owner's control responsibilities
  • A note of when the structure was last revised and what business change prompted it

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC1.3 — Organizational structure, authorities and responsibilities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC1.4: Competence and development of personnel [SOC 2 Trust Services Criteria: own-words representation; CC1.4]
  What's needed: This is a management action, not a software task: hiring, developing, retaining and planning succession for the people the system depends on is done by the organization, not a tool. A CPA auditor will expect to see the competence each control-relevant role requires, evidence that holders are trained and evaluated against it, and a plan for the roles whose loss would hurt — the security lead, the person who holds production access.

  • Defined competence or role requirements for security- and control-relevant positions
  • Training records and completion evidence tied to those requirements
  • Periodic competence or performance evaluations for the relevant roles
  • A succession or backup plan for roles the system critically depends on

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC1.4 — Competence and development of personnel — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC1.5: Accountability for internal control [SOC 2 Trust Services Criteria: own-words representation; CC1.5]
  What's needed: This is a management action, not a software task: accountability is created by how the organization measures, rewards and corrects people, which sits with management. A CPA auditor will expect to see that internal-control responsibilities carry real consequences — objectives or performance measures that include control duties, and evidence that shortfalls are addressed — and that incentives do not quietly reward bypassing controls to hit a deadline.

  • Performance objectives or measures that explicitly include control and security responsibilities
  • Evidence that a control shortfall led to a corrective conversation or consequence
  • A statement of how incentives are designed not to reward bypassing controls
  • Records showing accountability extends to contractors and third parties where relevant

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC1.5 — Accountability for internal control — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC2.1: Quality information for internal control [SOC 2 Trust Services Criteria: own-words representation; CC2.1]
  What's needed: Work out what information your controls actually need to run — access logs, alerts, asset inventories, vendor reports — and make sure you are getting it, from inside and outside the organization, at a quality good enough to rely on. A CPA auditor will expect to see that the information feeding key controls is accurate, complete and timely, and that someone owns keeping the sources current when systems change.

  • A list of the information sources each key control depends on, internal and external
  • Evidence the information is current and complete (for example log-coverage or inventory checks)
  • A named owner for maintaining each critical information source
  • An example where a data-quality gap in a control input was found and corrected

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC2.1 — Quality information for internal control — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC2.2: Internal communication [SOC 2 Trust Services Criteria: own-words representation; CC2.2]
  What's needed: Make sure the people inside the organization know the security commitments and control responsibilities they are meant to carry, how changes reach them, and how to raise a problem — including a channel to report concerns without fear. A CPA auditor will expect evidence that objectives and responsibilities were actually communicated, not just written, and that a reporting route exists and is known and used.

  • Published security policies and commitments, with evidence staff were made aware of them
  • A record of how security-relevant changes are communicated to affected teams
  • A documented reporting channel, including an anonymous route, for control and security concerns
  • Evidence the channel is known and used — an awareness note or a logged report

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC2.2 — Internal communication — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC2.3: Communication with external parties [SOC 2 Trust Services Criteria: own-words representation; CC2.3]
  What's needed: Tell the outside parties that need to know — customers, vendors, regulators — the things that bear on your controls: the commitments you make about the system, how you will notify them of incidents you have promised to report, and how they can reach you with a problem. A CPA auditor will expect to see the commitments you publish and the process behind any notification obligations you have taken on.

  • Published system commitments or terms describing what customers can rely on
  • A documented process for the incident or breach notifications you have committed to
  • A channel for external parties to report issues, with evidence it is monitored
  • An example external communication (a status notice or customer security update) sent in practice

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC2.3 — Communication with external parties — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC3.1: Clarity of objectives for risk assessment [SOC 2 Trust Services Criteria: own-words representation; CC3.1]
  What's needed: Write down the service commitments and system requirements clearly enough that you can point at what could go wrong. A CPA auditor will expect to see the objectives your controls exist to protect — availability targets, confidentiality promises, processing expectations — stated specifically, with the risk tolerances that tell you when a risk is out of bounds, because you cannot assess risk against an objective you never pinned down.

  • A documented statement of service commitments and system requirements
  • Defined risk tolerances or thresholds tied to those objectives
  • Evidence the objectives are specific enough to identify risks against
  • A note of who owns the objectives and when they were last reviewed

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC3.1 — Clarity of objectives for risk assessment — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC3.2: Risk identification and analysis [SOC 2 Trust Services Criteria: own-words representation; CC3.2]
  What's needed: Run a real risk assessment: identify the risks to your objectives across the business, the system's assets, your vendors and the threat environment, then judge each one's likelihood and impact so you can decide what to do about it. A CPA auditor will expect to see a dated assessment that was actually used to drive control decisions — not a one-time spreadsheet nobody revisited.

  • A dated risk assessment covering the system's assets, vendors and threat environment
  • Likelihood and impact analysis for each identified risk
  • A link from assessed risks to the controls or treatments chosen to address them
  • Evidence the assessment is refreshed on a defined cadence

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC3.2 — Risk identification and analysis — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC3.3: Fraud risk consideration [SOC 2 Trust Services Criteria: own-words representation; CC3.3]
  What's needed: Include fraud and abuse explicitly when you assess risk: fraudulent reporting, theft of assets, unauthorized or misused system access, and management overriding controls. A CPA auditor will expect to see that you thought about who could act against the system and how incentives or opportunities enable it — insider misuse of access is the case most startups skip — and that this shaped controls like segregation of duties and logging.

  • A fraud-risk section in the risk assessment covering asset misappropriation and access misuse
  • Consideration of management override of controls and how it is mitigated
  • Controls tied to identified fraud risks (segregation of duties, privileged-access logging)
  • A note of who reviewed the fraud-risk analysis and when

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC3.3 — Fraud risk consideration — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC3.4: Assessing significant change [SOC 2 Trust Services Criteria: own-words representation; CC3.4]
  What's needed: Treat significant change as a trigger to re-look at your risks: a new product line, a shift in the threat or regulatory environment, a leadership or technology change, a major system rework. A CPA auditor will expect to see that changes like these actually caused the risk assessment to be revisited, rather than the assessment ageing quietly while the business it describes moved on.

  • A defined list of change types that trigger a risk re-assessment
  • An example where a significant change led to an updated risk assessment
  • Evidence changes to the system are fed into the risk process (change and risk records linked)
  • A dated review confirming the assessment still reflects the current environment

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC3.4 — Assessing significant change — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC4.1: Ongoing and separate evaluations [SOC 2 Trust Services Criteria: own-words representation; CC4.1]
  What's needed: Check that your controls are actually present and working, both continuously and through point-in-time evaluations — control self-assessments, internal audits, vulnerability scans, penetration tests. A CPA auditor will expect to see a mix of monitoring and independent evaluation on a defined schedule, and that the results were recorded, because a control nobody ever checks is a control nobody can vouch for.

  • A schedule of ongoing monitoring and separate evaluations (self-assessment, internal audit)
  • Vulnerability-scan and penetration-test reports at a defined frequency
  • Records of evaluation results, including what was found and what passed
  • Evidence the evaluations cover the controls that matter most to the objectives

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC4.1 — Ongoing and separate evaluations — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC4.2: Evaluation and communication of deficiencies [SOC 2 Trust Services Criteria: own-words representation; CC4.2]
  What's needed: When an evaluation finds a control deficiency, get it to someone who can fix it, quickly, and track it to closure. A CPA auditor will expect to see that findings from scans, audits and incidents are logged, rated, assigned to an owner, escalated to management or the board where they are serious, and actually remediated — the trail from found to fixed is what turns a finding into evidence of a working process.

  • A tracked register of control deficiencies with owner, severity and status
  • Evidence serious deficiencies were escalated to senior management or the oversight body
  • Remediation records showing findings driven to closure with dates
  • A note of how remediation timeliness is monitored against target

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC4.2 — Evaluation and communication of deficiencies — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC5.1: Control activities that mitigate risk [SOC 2 Trust Services Criteria: own-words representation; CC5.1]
  What's needed: Choose and build the controls that bring your identified risks down to a level you can live with, mixing preventive and detective, manual and automated, with segregation of duties where the team is big enough to allow it. A CPA auditor will expect to see a clear line from each significant risk to the control activities chosen to address it, and a reason those controls are proportionate to the risk.

  • A mapping from significant risks to the control activities that address them
  • Evidence of both preventive and detective controls in the mix
  • Segregation-of-duties arrangements, or a documented compensating control where team size prevents it
  • A note of who selected the controls and how proportionality was judged

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC5.1 — Control activities that mitigate risk — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC5.2: General controls over technology [SOC 2 Trust Services Criteria: own-words representation; CC5.2]
  What's needed: Put the general technology controls in place that everything else rests on: control over the infrastructure itself, over security administration, and over how technology is acquired, built and maintained. A CPA auditor will expect to see that access to infrastructure is governed, that security configuration is managed rather than ad hoc, and that new or changed technology goes through a controlled path before it reaches production.

  • Documented controls over infrastructure access and administration
  • Security-configuration baselines or standards for key technology components
  • Controls over acquisition, development and maintenance of technology
  • Evidence these general controls are monitored for continued operation

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC5.2 — General controls over technology — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC5.3: Deployment through policies and procedures [SOC 2 Trust Services Criteria: own-words representation; CC5.3]
  What's needed: Turn your control intentions into policies that say what is expected and procedures that say how it is done, then make sure competent people actually carry them out on time. A CPA auditor will expect to see that policies exist, have named owners, are approved and reviewed, and — the part that gets skipped — that the procedures under them are followed in practice, not just filed.

  • Approved policies with named owners and a defined review cadence
  • Procedures that operationalize each policy, at a usable level of detail
  • Evidence procedures are performed (tickets, logs, sign-offs) by competent staff
  • A record of the last policy review and any resulting changes

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC5.3 — Deployment through policies and procedures — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC6.1: Logical access security over protected assets [SOC 2 Trust Services Criteria: own-words representation; CC6.1]
  What's needed: Protect your information assets with real logical access controls: know what the assets are, manage identities and credentials, restrict access and especially privileged rights to people who are authorized, protect your encryption keys, and encrypt or otherwise protect data at rest. A CPA auditor will expect to see the access architecture described and evidence it operates — an inventory, an identity model, key handling, and encryption actually enabled.

  • An inventory of the protected information assets in the report's scope
  • Identity and credential management, including how privileged rights are restricted
  • Evidence of encryption at rest and documented encryption-key handling
  • Access configuration showing least-privilege enforcement on key systems

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC6.1 — Logical access security over protected assets — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC6.2: User registration, authorization and deprovisioning [SOC 2 Trust Services Criteria: own-words representation; CC6.2]
  What's needed: Control the joiner-mover-leaver lifecycle: authorize new users before issuing credentials, review whether existing access is still appropriate, and remove access promptly when someone leaves or no longer needs it. A CPA auditor will expect to see approvals before access is granted, periodic access reviews with evidence of action, and — the finding that recurs most — timely deprovisioning proven against actual leaver dates.

  • Access-request and approval records showing authorization before credentials were issued
  • Periodic access reviews with evidence that inappropriate access was removed
  • Deprovisioning records tied to leaver dates, showing prompt removal
  • A reconciliation of active accounts against current personnel

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC6.2 — User registration, authorization and deprovisioning — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC6.3: Role-based access, least privilege and segregation [SOC 2 Trust Services Criteria: own-words representation; CC6.3]
  What's needed: Grant, change and remove access to data, systems and functions on the basis of role and need, applying least privilege and separating incompatible duties, and review periodically that people's access still matches their job. A CPA auditor will expect to see access driven by defined roles rather than ad hoc grants, evidence that privileged and sensitive access is tightly held, and reviews that actually pruned access.

  • A role-to-access mapping showing access is assigned by role and need
  • Evidence of least-privilege and segregation-of-duties in the access model
  • Periodic access-appropriateness reviews with resulting changes
  • Records of access modifications following role changes

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC6.3 — Role-based access, least privilege and segregation — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC6.4: Physical access restriction [SOC 2 Trust Services Criteria: own-words representation; CC6.4]
  What's needed: Applies where you control facilities, offices or storage that hold protected information; if you run entirely on a subservice cloud provider, physical access is addressed by their controls and the complementary controls you rely on — record that scoping decision and the reason in your system description and confirm the boundary with your auditor. Where it applies, restrict facility access to authorized people and revoke it promptly when no longer needed.

  • A record of the physical scope: which facilities you control versus inherit from a provider
  • Physical access controls and authorization records for any facilities in the report's scope
  • Evidence physical access is revoked promptly when no longer required
  • For inherited infrastructure, the provider's attestation report and your complementary controls

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC6.4 — Physical access restriction — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC6.5: Secure disposal of assets and data [SOC 2 Trust Services Criteria: own-words representation; CC6.5]
  What's needed: Applies where you control physical media or storage devices that hold protected information; if storage is fully managed by a subservice cloud provider, media sanitization is addressed by their controls — record that scoping decision and the reason in your system description. Where it applies, sanitize or destroy data before an asset leaves your control, and keep evidence it happened, so retired hardware cannot leak what it once held.

  • A record of the disposal scope: media you control versus provider-managed storage
  • A documented sanitization or destruction procedure for retired media
  • Disposal records (a signed destruction record or a wipe log) for assets removed
  • For provider-managed storage, reliance on the provider's documented media handling

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC6.5 — Secure disposal of assets and data — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC6.6: Protection against external threats [SOC 2 Trust Services Criteria: own-words representation; CC6.6]
  What's needed: Defend the boundary between your system and the outside world: boundary protection such as firewalls, hardened and authenticated external access points, and protection like encryption for data crossing public networks. A CPA auditor will expect to see the network boundary described and the controls proven — firewall or security-group rules under change control, no unauthenticated admin surface, and encryption on external traffic.

  • Boundary-protection configuration (firewall or security-group rules) under change control
  • Evidence external access points are hardened and require authentication
  • Encryption-in-transit configuration for data crossing public networks
  • A network diagram showing the system boundary and its protections

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC6.6 — Protection against external threats — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC6.7: Protection of information in transmission and movement [SOC 2 Trust Services Criteria: own-words representation; CC6.7]
  What's needed: Control how information moves and leaves: restrict transmission, movement and removal to authorized users and processes, and protect the data while it moves — encryption in transit, control over removable media, and protections on the laptops and phones that touch it. A CPA auditor will expect to see that data in motion is encrypted, that endpoints are managed, and that uncontrolled exfiltration routes are closed off.

  • Encryption-in-transit settings for internal and external data movement
  • Endpoint-protection and management configuration for devices that handle data
  • Controls over removable media, or evidence its use is blocked
  • Restrictions on who and what may transmit or export protected information

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC6.7 — Protection of information in transmission and movement — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC6.8: Prevention and detection of unauthorized or malicious software [SOC 2 Trust Services Criteria: own-words representation; CC6.8]
  What's needed: Keep untrusted code off the estate: control what software can be installed and run through configuration baselines and allowlisting where practical, deploy anti-malware to catch what slips through, patch promptly, and respond when something malicious turns up. A CPA auditor will expect to see the controls that stop unauthorized software and the evidence they run — coverage, patch cadence, and a handled detection.

  • Configuration baselines or allowlisting that constrain what software can run
  • Anti-malware deployment with coverage and update evidence
  • A patch-management process with evidence of timely patching
  • A record of a malware detection and how it was handled

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC6.8 — Prevention and detection of unauthorized or malicious software — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC7.1: Vulnerability and configuration-change detection [SOC 2 Trust Services Criteria: own-words representation; CC7.1]
  What's needed: Notice when your systems drift into a vulnerable state or when a new vulnerability is disclosed that affects you: monitor configuration for changes that introduce weakness, and scan on a regular cadence for known vulnerabilities. A CPA auditor will expect to see scanning and configuration monitoring actually running, with results triaged, so newly introduced or newly disclosed weaknesses are found before an attacker finds them.

  • Configuration monitoring that flags changes introducing vulnerabilities
  • Vulnerability-scan results on a defined, regular cadence
  • Evidence findings are triaged by severity and routed for remediation
  • A record showing detection-to-remediation timing is tracked

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC7.1 — Vulnerability and configuration-change detection — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC7.2: Monitoring for anomalies and security events [SOC 2 Trust Services Criteria: own-words representation; CC7.2]
  What's needed: Watch the running system for signs of trouble — anomalies that could mean an attack, a failure or an error — and analyze what you detect to decide whether it is a security event. A CPA auditor will expect to see monitoring and alerting across the components that matter, log coverage sufficient to investigate, and evidence that alerts are actually looked at rather than firing into an unwatched channel.

  • Monitoring and alerting configuration across key system components
  • Log coverage and retention sufficient to investigate an event
  • Evidence alerts are reviewed and triaged by a responsible owner
  • An example anomaly that was analyzed and dispositioned

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC7.2 — Monitoring for anomalies and security events — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC7.3: Evaluation of security events [SOC 2 Trust Services Criteria: own-words representation; CC7.3]
  What's needed: When a security event is detected, work out whether it did or could have stopped you meeting your objectives — whether it is an incident — and act where it did. A CPA auditor will expect to see criteria for deciding when an event becomes an incident, evidence that detected events were evaluated against those criteria, and that the ones that mattered were escalated into the response process rather than quietly closed.

  • Documented criteria for classifying an event as a security incident
  • Records of security events evaluated against those criteria
  • Evidence incidents were escalated into the response process
  • A note of how near-misses are captured and learned from

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC7.3 — Evaluation of security events — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC7.4: Security incident response [SOC 2 Trust Services Criteria: own-words representation; CC7.4]
  What's needed: Have an incident-response plan ready before you need it and run every confirmed incident through it: defined roles, containment, investigation, remediation, the communications and notifications you have committed to, and a formal close-out. A CPA auditor will expect to see the plan, evidence it has been exercised, and — where an incident occurred — the trail showing it was actually worked through end to end.

  • A documented incident-response plan with defined roles and responder duties
  • Evidence the plan was tested (a tabletop or a real-incident post-mortem)
  • For any incident, records of containment, investigation, remediation and close-out
  • Evidence committed notifications were made within the required timeframe

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC7.4 — Security incident response — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC7.5: Recovery from security incidents [SOC 2 Trust Services Criteria: own-words representation; CC7.5]
  What's needed: Be able to recover after an incident: restore the affected environment and data, verify the restoration actually worked, and feed what you learned back into your response plan and controls. A CPA auditor will expect to see recovery procedures, evidence they have been exercised, and lessons learned that changed something — recovery you have never tested is a plan, not a capability.

  • Documented recovery procedures for affected systems and data
  • Evidence of a recovery or restoration test with its results
  • A lessons-learned record from an incident or exercise
  • Evidence a lesson learned actually changed a procedure or control

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC7.5 — Recovery from security incidents — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC8.1: Controlled change management [SOC 2 Trust Services Criteria: own-words representation; CC8.1]
  What's needed: Run changes through a controlled path: nothing reaches production code, data structures or operating procedures until it has been requested, risk-assessed, built and tested away from production, documented and approved by someone other than its author. A CPA auditor will expect to see the change trail, independent approval, separation of environments, and an after-the-fact review route for emergency fixes — plus production data kept out of test.

  • Change records showing request, testing, documentation and approval before release
  • Evidence approvals are made by someone other than the change's author
  • Separation of development, test and production environments
  • An emergency-change process with after-the-fact review evidence

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC8.1 — Controlled change management — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC9.1: Mitigation of business-disruption risk [SOC 2 Trust Services Criteria: own-words representation; CC9.1]
  What's needed: Plan for the disruptions that could stop the service — an outage, a disaster, the loss of a key dependency — by identifying them and building mitigation, and consider insurance or other means to absorb the residual financial impact. A CPA auditor will expect to see a business-continuity and disaster-recovery approach tied to your availability commitments; the insurance decision itself is management's, but the plan behind it is evidence.

  • A business-continuity or disaster-recovery plan addressing key disruption scenarios
  • Recovery objectives (RTO/RPO) aligned to availability commitments
  • Evidence the plan is tested and maintained
  • A record of the residual-risk treatment decision, including insurance where used

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC9.1 — Mitigation of business-disruption risk — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• CC9.2: Vendor and business-partner risk management [SOC 2 Trust Services Criteria: own-words representation; CC9.2]
  What's needed: Manage the risk your vendors and subservice organizations carry across the whole relationship: due diligence before onboarding, security, confidentiality and privacy commitments in the contract, ongoing monitoring, incident-notification obligations, and clean termination. A CPA auditor will expect to see a vendor inventory, risk-based assessment of the ones that matter, and evidence you actually monitor them — the choosing and negotiating is yours, the tracking is documentation.

  • A vendor and subservice-organization inventory with risk ratings
  • Due-diligence records and contractual security, confidentiality and privacy commitments
  • Ongoing monitoring evidence (reviewing the vendor's own attestation report, for example)
  • Incident-notification clauses and a defined secure-termination process

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), CC9.2 — Vendor and business-partner risk management — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A1.1: Capacity management [SOC 2 Trust Services Criteria: own-words representation; A1.1]
  What's needed: Capacity management means never being surprised by your own growth: measure how much compute, storage and network the system actually consumes, project demand against the limits you have today, and grow or rebalance ahead of need so your availability commitments hold. A CPA auditor will expect to see utilization actually monitored, a forecasting basis, and evidence you expanded capacity in response — not just dashboards nobody acts on.

  • Utilization monitoring for compute, storage and network resources
  • Capacity forecasting against defined limits or thresholds
  • Evidence of a capacity change made ahead of a forecast constraint
  • Alerting that triggers before resource exhaustion

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), A1.1 — Capacity management — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A1.2: Environmental protections, backup and recovery infrastructure [SOC 2 Trust Services Criteria: own-words representation; A1.2]
  What's needed: Put in place and keep running the things availability rests on: environmental protections, the backup processes that capture your data, and the recovery infrastructure that brings the service back. A CPA auditor will expect to see backups configured and monitored, recovery infrastructure that exists and is maintained, and — for cloud-hosted systems — reliance on the provider's environmental controls documented rather than assumed.

  • Backup configuration with evidence backups run and are monitored for success
  • Documented recovery infrastructure and how it is maintained
  • Evidence of environmental protections, or documented reliance on the provider's controls
  • Monitoring or alerting on backup failures

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), A1.2 — Environmental protections, backup and recovery infrastructure — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A1.3: Recovery plan testing [SOC 2 Trust Services Criteria: own-words representation; A1.3]
  What's needed: Prove your recovery actually works by testing it — restore from backup, exercise failover — often enough and realistically enough to trust it against your availability commitments. A CPA auditor will expect to see recovery tests performed on a schedule, with results recorded and failures followed up, because a backup you have never restored is an assumption, not a control.

  • A schedule of recovery and backup-restoration tests
  • Results of a restoration or failover test, including what was verified
  • Follow-up records for any test that revealed a gap
  • Evidence test realism matches the availability commitments

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), A1.3 — Recovery plan testing — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• C1.1: Identification and protection of confidential information [SOC 2 Trust Services Criteria: own-words representation; C1.1]
  What's needed: Know what counts as confidential the moment you receive or create it, and protect it for as long as you hold it, in line with what you have promised. A CPA auditor will expect to see how confidential information is identified and labelled, the controls that protect it through its life, and that the protection matches your confidentiality commitments — not a blanket claim that everything is secure.

  • A definition and, where used, labelling of what the entity treats as confidential
  • Controls protecting confidential information in storage and use
  • A mapping from confidentiality commitments to the controls that meet them
  • Evidence access to confidential information is restricted to those who need it

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), C1.1 — Identification and protection of confidential information — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• C1.2: Disposal of confidential information [SOC 2 Trust Services Criteria: own-words representation; C1.2]
  What's needed: When you no longer need confidential information, get rid of it: erase or destroy it in line with your commitments, and do not forget the copies — backups, and anything held by third parties. A CPA auditor will expect to see a retention-and-disposal approach for confidential information and evidence disposal actually happens, including how backup copies age out and how third parties are held to the same.

  • A retention-and-disposal schedule for confidential information
  • Evidence disposal occurs when the retention purpose ends
  • How backup copies are aged out or made unrecoverable
  • Third-party commitments to dispose of confidential information they hold

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), C1.2 — Disposal of confidential information — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• PI1.1: Information about processing objectives and specifications [SOC 2 Trust Services Criteria: own-words representation; PI1.1]
  What's needed: Be clear about what your processing is supposed to do: define the data you process and the specifications of the products and services built on it, so correct has a meaning you can test against. A CPA auditor will expect to see documented processing objectives and definitions that are specific enough to judge completeness and accuracy against — vague intent cannot be examined for integrity.

  • Documented definitions of the data processed and its meaning
  • Specifications for the products or services the processing produces
  • Evidence the specifications are kept current with the system
  • A note of who owns the processing objectives

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), PI1.1 — Information about processing objectives and specifications — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• PI1.2: Completeness and accuracy of system inputs [SOC 2 Trust Services Criteria: own-words representation; PI1.2]
  What's needed: Control what enters processing so it is complete, accurate and authorized: validate inputs, reject or flag what fails, and make sure only authorized data gets in. A CPA auditor will expect to see input controls — validation rules, reconciliation, authorization checks — and evidence they catch bad input rather than passing it downstream, because integrity lost at the input is integrity lost everywhere after.

  • Input-validation rules and the errors they reject or flag
  • Authorization controls over what data may enter processing
  • Reconciliation or completeness checks on input batches or streams
  • Evidence rejected inputs are handled rather than silently dropped

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), PI1.2 — Completeness and accuracy of system inputs — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• PI1.3: Processing to specification [SOC 2 Trust Services Criteria: own-words representation; PI1.3]
  What's needed: Make sure processing does what the specification says — completely, accurately, on time and only as authorized — and that deviations are caught and corrected. A CPA auditor will expect to see controls over the processing itself, monitoring that detects when output diverges from specification, and a record that detected deviations were actually investigated and fixed rather than tolerated.

  • Controls ensuring processing runs completely and accurately to specification
  • Monitoring that detects processing deviations or failures
  • Records of detected deviations and their correction
  • Evidence processing timeliness is tracked against expectations

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), PI1.3 — Processing to specification — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• PI1.4: Completeness, accuracy and delivery of outputs [SOC 2 Trust Services Criteria: own-words representation; PI1.4]
  What's needed: Get outputs right and get them only to the right people: complete, accurate, on time, and delivered to the intended recipients. A CPA auditor will expect to see output controls — checks that results are complete and accurate before release, and controls over distribution — with evidence that misdirected or incomplete output is prevented or caught, since a correct result sent to the wrong recipient is still a failure.

  • Output-accuracy and completeness checks before release
  • Controls over who receives output and how it is distributed
  • Evidence output timeliness is monitored against commitments
  • A record of a caught output error and its correction

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), PI1.4 — Completeness, accuracy and delivery of outputs — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• PI1.5: Protection of stored inputs, in-process items and outputs [SOC 2 Trust Services Criteria: own-words representation; PI1.5]
  What's needed: Protect data at every stage of processing — inputs waiting to be processed, items mid-flight, and finished outputs — so nothing is lost or altered without authorization while it sits or moves. A CPA auditor will expect to see controls that keep stored and in-process data complete and unchanged except as authorized, and evidence those protections hold across the whole processing pipeline, not just at rest.

  • Controls protecting stored inputs and outputs from unauthorized change
  • Integrity controls over items during processing
  • Evidence of authorization around any change to in-process data
  • Monitoring or checks that detect unauthorized alteration

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), PI1.5 — Protection of stored inputs, in-process items and outputs — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P1.1: Privacy notice [SOC 2 Trust Services Criteria: own-words representation; P1.1]
  What's needed: Tell people what you do with their personal information: what you collect, why, and how you use, keep, share and dispose of it — and keep that notice current, accurate and easy to find. A CPA auditor will expect to see a published privacy notice that matches what the system actually does, and evidence it is maintained, because a notice that has drifted from practice is a finding in itself.

  • A published, dated privacy notice covering collection, use, retention, disclosure and disposal
  • Evidence the notice reflects actual data practices
  • A record of notice reviews and updates
  • Evidence the notice is readily available to data subjects

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P1.1 — Privacy notice — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P2.1: Choice and consent [SOC 2 Trust Services Criteria: own-words representation; P2.1]
  What's needed: Give people the choices they are owed over their personal information — collection, use, retention, disclosure, disposal — and obtain the consent your practices depend on, in the form the circumstances require. A CPA auditor will expect to see the choices communicated, the consent mechanism, and records that consent was actually captured where your processing relies on it.

  • Documentation of the choices offered to data subjects
  • The consent mechanism and the wording presented
  • Records evidencing consent was obtained where required
  • A process for honoring changes to or withdrawal of consent

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P2.1 — Choice and consent — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P3.1: Collection limited to identified objectives [SOC 2 Trust Services Criteria: own-words representation; P3.1]
  What's needed: Collect personal information only in ways, and for purposes, that match what your privacy notice and commitments say — no quiet collection for uses you never disclosed. A CPA auditor will expect to see that what you actually collect lines up with your stated objectives, and evidence of a check that new collection points are assessed against the notice before they go live.

  • A mapping of collection points to the purposes in the privacy notice
  • Evidence collection is limited to disclosed purposes
  • A review step for new collection against the notice
  • A data inventory covering what personal information is collected

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P3.1 — Collection limited to identified objectives — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P3.2: Explicit consent where required [SOC 2 Trust Services Criteria: own-words representation; P3.2]
  What's needed: Where the information is sensitive, or the law or your commitments require it, get explicit consent at or before the point of collection and keep the record. A CPA auditor will expect to see how sensitive personal information is identified, the explicit-consent step in front of it, and evidence that consent was captured and stored — implicit consent is not enough for the categories that demand more.

  • How sensitive personal information is identified and flagged
  • The explicit-consent mechanism used at or before collection
  • Stored records of explicit consent with timestamps
  • Evidence collection is blocked where required consent is absent

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P3.2 — Explicit consent where required — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P4.1: Use limited to identified purposes [SOC 2 Trust Services Criteria: own-words representation; P4.1]
  What's needed: Use personal information only for the purposes you disclosed and consented to — not for a new use bolted on later without going back to the person. A CPA auditor will expect to see controls that keep data use inside its stated purposes, and evidence that a proposed new use triggers a check against the notice and consent rather than just happening.

  • Controls limiting use of personal information to disclosed purposes
  • A review step for any new or secondary use
  • Evidence access to personal information is tied to permitted purposes
  • A record of a use request assessed against the notice

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P4.1 — Use limited to identified purposes — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P4.2: Retention limited to need [SOC 2 Trust Services Criteria: own-words representation; P4.2]
  What's needed: Keep personal information only as long as you need it for the stated purpose, or as the law requires, under a retention policy you actually enforce. A CPA auditor will expect to see defined retention periods and evidence they are enforced — data that should have aged out but is still sitting in the system is one of the most common privacy findings.

  • A retention policy with defined periods per data category
  • Evidence retention periods are enforced (automated ageing or reviewed deletions)
  • A record of retention decisions where law extends or limits the period
  • Evidence retained data is reviewed against the policy

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P4.2 — Retention limited to need — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P4.3: Secure disposal of personal information [SOC 2 Trust Services Criteria: own-words representation; P4.3]
  What's needed: When retention ends, actually dispose of the personal information — delete, anonymize or destroy it — and keep evidence it happened, including copies in backups. A CPA auditor will expect to see a disposal mechanism tied to the retention policy and records proving disposal occurred, because a retention rule with no disposal behind it protects nobody.

  • A disposal, anonymization or destruction mechanism tied to retention
  • Records evidencing disposal actually occurred
  • How personal information in backups is aged out
  • Evidence disposal covers all systems holding the data

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P4.3 — Secure disposal of personal information — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P5.1: Data subject access [SOC 2 Trust Services Criteria: own-words representation; P5.1]
  What's needed: Let people see the personal information you hold about them and, where appropriate, correct or update it. A CPA auditor will expect to see a process for handling access and correction requests — how a request is received, verified, fulfilled and tracked — and evidence it runs within any committed timeframe, not just that a policy says it exists.

  • A documented access-and-correction request process
  • Identity-verification steps for requesters
  • Records of fulfilled access and correction requests with dates
  • Evidence requests are handled within committed timeframes

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P5.1 — Data subject access — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P5.2: Handling of denied access requests [SOC 2 Trust Services Criteria: own-words representation; P5.2]
  What's needed: When you deny an access or correction request, tell the person, give the reason where you must, and keep a record of the denial. A CPA auditor will expect to see the criteria under which a request may be denied, evidence denials are communicated with any required reason, and a log of denied requests — an undocumented denial looks like a request that was simply ignored.

  • Criteria for when an access or correction request may be denied
  • Evidence denials are communicated to the data subject with required reasons
  • A retained log of denied requests
  • A route for the data subject to challenge a denial where provided

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P5.2 — Handling of denied access requests — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P6.1: Disclosure limited to consent and objectives [SOC 2 Trust Services Criteria: own-words representation; P6.1]
  What's needed: Disclose personal information to third parties only with consent or in line with the purposes and commitments you disclosed — no sharing the person would not expect from your notice. A CPA auditor will expect to see controls over disclosure, a basis recorded for the disclosures you do make, and evidence that unauthorized sharing is prevented.

  • Controls governing disclosure of personal information to third parties
  • The recorded basis (consent or disclosed purpose) for each disclosure type
  • Evidence disclosures outside the permitted basis are prevented
  • An inventory of third parties that receive personal information

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P6.1 — Disclosure limited to consent and objectives — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P6.2: Record of authorized disclosures [SOC 2 Trust Services Criteria: own-words representation; P6.2]
  What's needed: Keep a complete, accurate and timely record of the authorized disclosures of personal information you make. A CPA auditor will expect to see a disclosure log that captures who received what and under what basis, current enough to answer a data subject or regulator, because a disclosure you cannot account for is a disclosure you cannot defend.

  • A log of authorized disclosures with recipient, data and basis
  • Evidence the log is complete and kept current
  • A link from logged disclosures to their authorizing basis
  • Evidence the record can be produced on request

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P6.2 — Record of authorized disclosures — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P6.3: Record of unauthorized disclosures [SOC 2 Trust Services Criteria: own-words representation; P6.3]
  What's needed: Record the unauthorized disclosures and breaches of personal information you detect or are told about, completely and promptly. A CPA auditor will expect to see that detected or reported incidents involving personal information are logged with enough detail to drive notification and remediation — the record is what your breach obligations are built on.

  • A log of detected or reported unauthorized disclosures and breaches
  • Detail sufficient to support notification decisions
  • A link to the incident-response and notification process
  • Evidence the record is created promptly on detection

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P6.3 — Record of unauthorized disclosures — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P6.4: Third-party privacy commitments [SOC 2 Trust Services Criteria: own-words representation; P6.4]
  What's needed: Get privacy commitments from the vendors and third parties who handle personal information for you, and check periodically that they are keeping them. A CPA auditor will expect to see contractual privacy obligations on those third parties and evidence of ongoing assessment — reviewing their reports or attestations — rather than a signature at onboarding and silence afterward.

  • Contractual privacy commitments from third parties handling personal information
  • An inventory of such third parties and what data they handle
  • Evidence of periodic assessment that commitments are being met
  • Follow-up records where a third-party gap was found

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P6.4 — Third-party privacy commitments — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P6.5: Third-party notification of unauthorized disclosures [SOC 2 Trust Services Criteria: own-words representation; P6.5]
  What's needed: Require your vendors and third parties to tell you about actual or suspected unauthorized disclosures of personal information, and act when they do. A CPA auditor will expect to see notification obligations written into third-party arrangements and evidence you have a route to receive and respond to such notifications, since much personal information now sits with processors rather than with you.

  • Contractual breach-notification obligations on third parties
  • A defined route to receive and triage third-party notifications
  • Evidence a received notification was acted on, where any occurred
  • A link from third-party notifications to your own response process

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P6.5 — Third-party notification of unauthorized disclosures — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P6.6: Breach notification to affected parties [SOC 2 Trust Services Criteria: own-words representation; P6.6]
  What's needed: When personal information is breached, tell the people and bodies who must hear it — affected data subjects, regulators, and anyone else your commitments or the law require — within the required timeframes. A CPA auditor will expect to see a notification process with criteria and timelines, and, for any breach that occurred, evidence the right parties were notified in time.

  • A breach-notification process with criteria and required timeframes
  • A mapping of who must be notified under commitments and applicable law
  • For any breach, records showing timely notification of affected parties
  • Evidence the process is tested or reviewed

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P6.6 — Breach notification to affected parties — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P6.7: Accounting of held information and disclosures [SOC 2 Trust Services Criteria: own-words representation; P6.7]
  What's needed: Be able to give a person, on request, an accounting of the personal information you hold about them and the disclosures you have made of it, in line with your commitments. A CPA auditor will expect to see that you can assemble this accounting — which depends on the disclosure and inventory records above — and evidence you have provided it when asked.

  • A process to compile an accounting of held information and disclosures
  • Reliance on the disclosure log and data inventory to build it
  • Records of accountings provided on request
  • Evidence the accounting is complete and timely

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P6.7 — Accounting of held information and disclosures — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P7.1: Accuracy and relevance of personal information [SOC 2 Trust Services Criteria: own-words representation; P7.1]
  What's needed: Keep the personal information you hold accurate, current, complete and fit for the purposes you stated — stale or wrong data is both a privacy problem and a quality one. A CPA auditor will expect to see mechanisms that keep data accurate (correction routes, validation, refresh) and evidence that irrelevant or outdated personal information is trimmed rather than kept indefinitely.

  • Mechanisms to keep personal information accurate and up to date
  • Correction and update routes for data subjects and staff
  • Evidence irrelevant or outdated data is identified and removed
  • A link between accuracy controls and the stated purposes

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P7.1 — Accuracy and relevance of personal information — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• P8.1: Privacy inquiries, complaints and enforcement [SOC 2 Trust Services Criteria: own-words representation; P8.1]
  What's needed: Give people a way to raise privacy inquiries, complaints and disputes, resolve them and record what happened, and monitor your own compliance with your privacy commitments so you find the gaps before a complaint does. A CPA auditor will expect to see a complaint-handling process, records of resolved matters, and evidence of periodic privacy monitoring that led to remediation.

  • A documented process to receive and resolve privacy inquiries and complaints
  • Records of complaints handled, with resolution and dates
  • Evidence of periodic monitoring of adherence to privacy commitments
  • Remediation records for deficiencies the monitoring found

  AICPA Trust Services Criteria (2017, with 2022 revised points of focus), P8.1 — Privacy inquiries, complaints and enforcement — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.

Criteria paraphrased in our own words and mapped to the AICPA 2017 Trust Services Criteria (with Revised Points of Focus, 2022) criterion numbering. Not the criteria themselves — obtain the authoritative document from AICPA. SOC 2 is attested by a licensed CPA firm; no software grants it. DRAFT pending internal review.

In force since January 1, 2026. Monitored: this law is under an active federal-preemption effort and may be narrowed or preempted.

• Tex. Bus. & Com. Code § 552.052: Prohibition: do not develop or deploy AI in a manner that intentionally aims to incite self-harm, harm to others, or criminal activity [Texas TRAIGA: Responsible Artificial Intelligence Governance Act (HB 149, 89th Leg., 2025); Tex. Bus. & Com. Code § 552.052]
• Tex. Bus. & Com. Code § 552.055: Prohibition: do not develop or deploy AI with the sole intent to infringe or impair rights guaranteed under the United States Constitution [Texas TRAIGA: Responsible Artificial Intelligence Governance Act (HB 149, 89th Leg., 2025); Tex. Bus. & Com. Code § 552.055]
• Tex. Bus. & Com. Code § 552.056: Prohibition: do not develop or deploy AI with the intent to unlawfully discriminate against a protected class [Texas TRAIGA: Responsible Artificial Intelligence Governance Act (HB 149, 89th Leg., 2025); Tex. Bus. & Com. Code § 552.056], Intent standard, § 552.056(c): a disparate impact is not sufficient by itself. Carve-outs in the cited text: regulated insurance entities (a definition that includes the developer of an AI system used by an insurer, § 552.056(a)(2)(C)) and federally insured financial institutions.
• Tex. Bus. & Com. Code § 552.057: Prohibition: no AI developed or distributed for child sexual abuse material, unlawful sexual deepfakes, or sexual text conversations impersonating a child [Texas TRAIGA: Responsible Artificial Intelligence Governance Act (HB 149, 89th Leg., 2025); Tex. Bus. & Com. Code § 552.057]
• Tex. Bus. & Com. Code § 552.105: Attorney General enforcement: civil penalties (curable, uncurable, and per-day tiers) and injunctions, after the statutory notice-and-cure process [Texas TRAIGA: Responsible Artificial Intelligence Governance Act (HB 149, 89th Leg., 2025); Tex. Bus. & Com. Code § 552.105], Statutory safe harbor, § 552.105(e)(2)(D): substantial compliance with the NIST Generative AI Profile (or another recognized AI risk framework) with an internal review process is a defense. The NIST GenAI Profile is served, cited, in the NIST section of this readiness view.

Source: Texas H.B. 149 (89th Legislature, R.S., 2025) — the Texas Responsible Artificial Intelligence Governance Act (Tex. Bus. & Com. Code Chs. 551–552). Text of law — an edict of government. IN FORCE since January 1, 2026 — monitored; under active federal-preemption pressure, may be narrowed or preempted. DRAFT pending internal review.

In force at EU level since December 8, 2024. A DIRECTIVE: it binds through member-state transpositions due by 9 December 2026, and the liability regime applies to products placed on the market or put into service after 9 December 2026. No national implementation is asserted here; national transposition laws are tracked as they land.

• Article 4: Your software, AI system, or model is a 'product': the definition covers all movables even when integrated into another product, and includes software and digital manufacturing files [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 4; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853]
• Article 5: Strict liability: any natural person who suffers damage caused by a defective product is entitled to compensation. No fault or negligence needs to be shown [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 5; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853]
• Article 8: Who is on the hook: the manufacturer (including anyone who substantially modifies a product), component manufacturers, and, for non-EU manufacturers, the importer, authorised representative, or fulfilment service provider [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 8; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853], Selling into the EU from outside does not avoid the regime. Article 8(1)(c) routes liability through your EU-side chain.
• Article 6: Covered damage includes death or personal injury (including medically recognised psychological harm), property damage, and destruction or corruption of non-professional data, with material and (under national law) non-material losses [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 6; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853]
• Article 7: A product is defective when it does not provide the safety a person is entitled to expect or that is required under Union or national law [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 7; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853]
• Article 9: Courts can order you to disclose relevant evidence at your disposal once a claimant shows a plausible claim (necessity/proportionality limits and trade-secret safeguards apply) [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 9; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853], Failing to disclose triggers the Article 10(2)(a) presumption that the product is defective.
• Article 10: Defectiveness is presumed on non-disclosure, non-compliance with mandatory safety requirements, or obvious malfunction; causation is presumed where the damage is typically consistent with the defect; and courts may presume either where technical or scientific complexity makes proof excessively difficult, squarely aimed at software and AI [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 10; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853], All presumptions are rebuttable (Article 10(5)). Rebuttal runs on evidence.
• Article 15: No contracting out: liability cannot be limited or excluded by a contractual provision or by national law. Terms of service do not shield you [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 15; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853]
• Article 11: The 'defect arose later' exemption is unavailable where the defect is due to a related service, software updates or upgrades, the LACK of updates needed to maintain safety, or a substantial modification, while within the manufacturer's control (Article 11(2)) [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 11; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853]
• Article 10: Mitigation: Compliance evidence rebuts the presumptions: demonstrable conformity with mandatory safety requirements defeats the Article 10(2)(b) trigger, and documented risk management supports rebuttal under Article 10(5) [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 10; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853]
• Article 9: Mitigation: Disclosure readiness: maintained technical documentation and logs turn a court disclosure order into a procedure instead of a crisis, and avoid the Article 10(2)(a) failure-to-disclose presumption [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 9; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853]
• Article 11: Mitigation: Preserving the defences: the later-defect (11(1)(c)) and development-risk (11(1)(e)) exemptions turn on proving the product's state and the state of knowledge when it was placed on the market. Post-market monitoring and logging evidence is what proves that [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 11; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853], Mind the Article 11(2) carve-back: the later-defect defence is lost for defects due to updates, lack of necessary updates, or related services within your control.
• Article 11: Mitigation: Update discipline: keeping safety-necessary updates flowing avoids the Article 11(2)(c) lack-of-updates liability that the update carve-back creates [Directive (EU) 2024/2853 (revised Product Liability Directive); Article 11; ELI http://data.europa.eu/eli/dir/2024/2853/oj; CELEX 32024L2853]

Source: Directive (EU) 2024/2853, © European Union, https://eur-lex.europa.eu, 1998–2026. Only EU legislation published in the electronic edition of the Official Journal of the European Union is deemed authentic. IN FORCE at EU level since December 8, 2024; member-state transpositions due 9 December 2026 and the regime applies to products placed on the market or put into service after that date — no national implementation is asserted here. Source text pinned and dated; automated change monitoring is not yet in place for this source. DRAFT pending internal review.

In force since December 10, 2024, and the obligations PHASE IN per Article 71: the Article 14 vulnerability-and-incident reporting duties apply from 11 September 2026 (to all products on the EU market, including those already placed), and the main essential requirements and manufacturer obligations apply from 11 December 2027 (products placed earlier are caught on substantial modification). Nothing on this checklist is enforceable against you before its own date.

• Article 2: You are in scope: the CRA reaches products with digital elements made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect data connection, which covers most software and AI products. [Regulation (EU) 2024/2847 (Cyber Resilience Act); Article 2; ELI http://data.europa.eu/eli/reg/2024/2847/oj; CELEX 32024R2847]
• Article 13: Design, develop and produce the product in accordance with the Annex I Part I essential cybersecurity requirements before placing it on the EU market. [Regulation (EU) 2024/2847 (Cyber Resilience Act); Article 13; ELI http://data.europa.eu/eli/reg/2024/2847/oj; CELEX 32024R2847], applies from 11 December 2027
• Article 13: Undertake and document a cybersecurity risk assessment for the product, keep it current through the support period, and include it in the technical documentation. [Regulation (EU) 2024/2847 (Cyber Resilience Act); Article 13; ELI http://data.europa.eu/eli/reg/2024/2847/oj; CELEX 32024R2847], applies from 11 December 2027
• Annex I: Meet the Annex I Part I product-security properties: no known exploitable vulnerabilities at release, secure-by-default configuration, security updates, access control, protection of confidentiality and integrity, data minimisation, availability/resilience, and security logging. [Regulation (EU) 2024/2847 (Cyber Resilience Act); Annex I; ELI http://data.europa.eu/eli/reg/2024/2847/oj; CELEX 32024R2847], applies from 11 December 2027
• Annex I: Operate the Annex I Part II vulnerability-handling processes: identify and document components (software bill of materials), handle and remediate vulnerabilities, a coordinated vulnerability disclosure policy, and security updates distributed for the support period. [Regulation (EU) 2024/2847 (Cyber Resilience Act); Annex I; ELI http://data.europa.eu/eli/reg/2024/2847/oj; CELEX 32024R2847], applies from 11 December 2027
• Article 14: Report any actively exploited vulnerability in the product to the coordinating CSIRT and ENISA: early warning within 24 hours of awareness, vulnerability notification within 72 hours, and a final report within 14 days of a corrective measure being available. [Regulation (EU) 2024/2847 (Cyber Resilience Act); Article 14; ELI http://data.europa.eu/eli/reg/2024/2847/oj; CELEX 32024R2847], applies from 11 September 2026
• Article 14: Report severe incidents having an impact on the security of the product on the same channel and cadence (24-hour early warning, 72-hour notification, final report), and inform impacted users without undue delay. [Regulation (EU) 2024/2847 (Cyber Resilience Act); Article 14; ELI http://data.europa.eu/eli/reg/2024/2847/oj; CELEX 32024R2847], applies from 11 September 2026
• Article 12: If the product is a high-risk AI system under the EU AI Act: meeting the CRA's Annex I essential requirements (Parts I and II) gives deemed compliance with the AI Act Article 15 cybersecurity requirements, in so far as that protection level is demonstrated in the EU declaration of conformity issued under the CRA. [Regulation (EU) 2024/2847 (Cyber Resilience Act); Article 12; ELI http://data.europa.eu/eli/reg/2024/2847/oj; CELEX 32024R2847], Stated as Article 12 states it; the deemed compliance is scoped to the declaration of conformity.

Source: Regulation (EU) 2024/2847, © European Union, https://eur-lex.europa.eu, 1998–2026. Only EU legislation published in the electronic edition of the Official Journal of the European Union is deemed authentic. IN FORCE since December 10, 2024; obligations phase in per Article 71 (reporting duties and the main essential requirements apply from the future dates stated in the ingested Article 71 text). Source text pinned and dated; automated change monitoring is not yet in place for this source. DRAFT pending internal review.

IN FORCE: Utah's generative-AI disclosure law (Utah Code Ch. 13-77; §§ 101-102 as amended in the 2026 General Session, §§ 103-105 as enacted in 2025. See the source attribution for the ingested versions). A VOLATILE state AI law monitored under active federal-preemption pressure; the official per-section pages are change-monitored. Monitored.

• Utah Code § 13-77-103: Disclose that the individual is interacting with generative AI and not a human whenever an individual clearly and unambiguously asks, in any consumer-transaction interaction. [Utah Code Title 13, Chapter 77 (Generative Artificial Intelligence) + § 63I-2-213; Utah Code § 13-77-103]
• Utah Code § 13-77-104: Safe harbor: clear and conspicuous disclosure at the outset and throughout the interaction ("is generative AI", "not human", or "an AI assistant") shields against § 13-77-103 enforcement, the cheap, always-on route most products should take. [Utah Code Title 13, Chapter 77 (Generative Artificial Intelligence) + § 63I-2-213; Utah Code § 13-77-104]
• Utah Code § 13-77-102: Using generative AI is no defense: a consumer-protection violation is still yours if the AI made the statement, undertook the act, or was used in furtherance of it. [Utah Code Title 13, Chapter 77 (Generative Artificial Intelligence) + § 63I-2-213; Utah Code § 13-77-102]
• Utah Code § 13-77-105: Enforcement context: the Division of Consumer Protection administers the chapter. Administrative fines up to $2,500 per violation, plus injunctions and disgorgement in court. [Utah Code Title 13, Chapter 77 (Generative Artificial Intelligence) + § 63I-2-213; Utah Code § 13-77-105]

Source: Utah Code §§ 13-77-101 through 13-77-105 and § 63I-2-213, Utah State Legislature, le.utah.gov (official per-section PDFs, retrieved 2026-07-05). IN FORCE — §§ 101-102 as amended effective May 6, 2026; §§ 103-105 effective May 7, 2025. The Chapter 77 disclosure duties carry NO scheduled repeal; the ingested § 63I-2-213 repeals only Title 13, Chapter 72 (the AI Policy Act program chapter) on the date stated in its text. Monitored — state AI law under active federal-preemption pressure. DRAFT pending internal review.

Pursuing: 70 controls to satisfy

• Clause 4.1: Understanding the organization and its context [ISO/IEC 42001 (AI management system): own-words representation; Clause 4.1]
  What's needed: Write down what your organization actually does with AI and which role you hold in each case — building it, deploying someone else's, or both — because that role decides which duties fall on you. Cover the internal factors (team, skills, existing systems) and the external ones (markets served, buyer demands, applicable law). Keep it dated and revisit it when the product changes.

  • A dated context analysis naming the internal and external factors that bear on your AI work
  • A statement of the role you hold for each AI system (provider, deployer, or both) and why
  • A record of the laws and buyer requirements you concluded are binding on you, with the reasoning
  • A note of when the analysis was last revisited and what changed

  ISO/IEC 42001:2023, Clause 4.1 — Understanding the organization and its context — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 4.2: Needs and expectations of interested parties [ISO/IEC 42001 (AI management system): own-words representation; Clause 4.2]
  What's needed: List who has a stake in your AI systems — customers, the people your system affects, regulators, investors, suppliers, your own staff — and write down what each of them requires of you. Separate the legally binding requirements from contractual ones and from expectations you have chosen to meet, because a reviewer will ask which is which.

  • A register of interested parties with each party's stated requirements
  • A split showing which requirements are legal, which contractual, and which voluntary
  • Evidence of how requirements were gathered (contracts, buyer questionnaires, regulatory analysis)
  • A review date and named owner for the register

  ISO/IEC 42001:2023, Clause 4.2 — Needs and expectations of interested parties — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 4.3: Scope of the AI management system [ISO/IEC 42001 (AI management system): own-words representation; Clause 4.3]
  What's needed: Draw the boundary: which AI systems, teams, sites and processes sit inside your management system and which do not, and state why each exclusion is out. A scope that quietly omits the AI system your buyers care about is the most common way this fails, so make the boundary something you would be comfortable showing a buyer's reviewer.

  • A documented scope statement naming the AI systems, organizational units and locations covered
  • The exclusions with a stated reason for each
  • The link from scope back to the context analysis and interested-party requirements
  • Approval of the scope by whoever owns it

  ISO/IEC 42001:2023, Clause 4.3 — Scope of the AI management system — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 4.4: AI management system [ISO/IEC 42001 (AI management system): own-words representation; Clause 4.4]
  What's needed: Show that the management system exists as a working set of processes rather than a folder of documents: what the processes are, how they hand off to each other, who owns each, and how they get improved. What a reviewer looks for is that the processes ran — dated outputs — not that they were written down.

  • A process map showing the AI management system's processes and their interactions
  • A named owner for each process
  • Dated outputs proving each process actually ran at least once
  • A record of improvements made to the system since it was established

  ISO/IEC 42001:2023, Clause 4.4 — AI management system — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 5.1: Leadership and commitment [ISO/IEC 42001 (AI management system): own-words representation; Clause 5.1]
  What's needed: This is a management action — no tool can perform it for you. Top management has to set the policy and objectives, fold the AI management system into how the business is actually run, and release the budget and people to operate it. What a reviewer looks for is a trail of decisions: approvals with names and dates, and resourcing that visibly happened.

  • The AI policy and objectives approved by a named member of top management, with the date
  • Minutes or decision records showing AI management-system matters reviewed at leadership level
  • Evidence of resources actually allocated — budget lines, headcount, tooling
  • A statement of how the AI management system connects to existing business processes

  ISO/IEC 42001:2023, Clause 5.1 — Leadership and commitment — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 5.2: AI policy [ISO/IEC 42001 (AI management system): own-words representation; Clause 5.2]
  What's needed: Produce an AI policy that fits your organization rather than a generic one: it should state your direction for AI, frame the objectives, commit you to meeting the requirements you identified, and commit you to improving. It has to be approved, published where the people bound by it can read it, and made available to interested parties who need it.

  • The approved AI policy, with approver, date and version
  • The distribution record showing who it reached and how
  • The link from each policy commitment to the requirements identified under Clause 4.2
  • A defined review cycle for the policy

  ISO/IEC 42001:2023, Clause 5.2 — AI policy — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 5.3: Roles, responsibilities and authorities [ISO/IEC 42001 (AI management system): own-words representation; Clause 5.3]
  What's needed: Name the people. For each role that touches AI — risk owner, system owner, whoever approves a release, whoever answers an incident — record who holds it, what they may decide, and what they must escalate. Then show the people concerned actually know: an assignment that never reached the person is the gap reviewers find.

  • A responsibility assignment covering the AI-relevant roles, naming the holders
  • The decision rights and escalation path for each role
  • Evidence the assignments were communicated and acknowledged
  • A record of how roles are reassigned when people change

  ISO/IEC 42001:2023, Clause 5.3 — Roles, responsibilities and authorities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 6.1.1: Actions to address risks and opportunities — general [ISO/IEC 42001 (AI management system): own-words representation; Clause 6.1.1]
  What's needed: Turn the context and interested-party work into planned actions. For each risk or opportunity you identified, record what you will do about it, where that action lives inside the management system rather than beside it, and how you will judge afterwards whether it worked. Actions with no owner and no evaluation step are the ones that quietly lapse.

  • A register of the risks and opportunities arising from context and interested-party requirements
  • The planned action for each, with an owner and a target date
  • Evidence the actions are integrated into the management-system processes
  • An evaluation record showing whether each action achieved what was intended

  ISO/IEC 42001:2023, Clause 6.1.1 — Actions to address risks and opportunities — general — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 6.1.2: AI risk assessment [ISO/IEC 42001 (AI management system): own-words representation; Clause 6.1.2]
  What's needed: Write down the method before you use it: what counts as an AI risk, the criteria for likelihood and consequence, the scale, and what level you are willing to accept. Then apply it the same way every time so two assessments a year apart can be compared. AI risk needs AI-specific criteria — a security risk method relabelled will not survive review.

  • A documented AI risk-assessment method with defined criteria and scales
  • The risk-acceptance criteria and who set them
  • At least one completed assessment produced with that method
  • Evidence the same method was applied across systems, so results are comparable

  ISO/IEC 42001:2023, Clause 6.1.2 — AI risk assessment — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 6.1.3: AI risk treatment [ISO/IEC 42001 (AI management system): own-words representation; Clause 6.1.3]
  What's needed: For each assessed risk decide what you are doing about it, pick the Annex A controls that implement that decision, and produce a Statement of Applicability that justifies every control you include and every one you exclude. Then have the risk owner accept whatever residual risk is left, in writing. The exclusion justifications are what reviewers read first.

  • A risk treatment plan linking each risk to its chosen treatment and controls
  • A Statement of Applicability covering all Annex A controls, with a justification for each inclusion and exclusion
  • Written risk-owner acceptance of the residual risk
  • Evidence the treatment plan is being implemented, not only approved

  ISO/IEC 42001:2023, Clause 6.1.3 — AI risk treatment — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 6.1.4: AI system impact assessment [ISO/IEC 42001 (AI management system): own-words representation; Clause 6.1.4]
  What's needed: Assess what your AI system could do to the people it touches and to wider society, not only what it could do to your organization. Record who could be affected, how, how badly, and what you changed as a result. The output has to feed the risk treatment — an impact assessment that lands nowhere is the failure mode here.

  • A completed impact assessment for each AI system in scope
  • The identification of affected individuals, groups and societal effects considered
  • The link from impact findings into the risk treatment plan
  • The trigger conditions that cause a reassessment

  ISO/IEC 42001:2023, Clause 6.1.4 — AI system impact assessment — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 6.2: AI objectives and planning to achieve them [ISO/IEC 42001 (AI management system): own-words representation; Clause 6.2]
  What's needed: Set AI objectives you can actually measure and that follow from the policy. For each one record what will be done, the resources it needs, who owns it, when it is due, and how the result will be evaluated. Objectives written as aspirations rather than measurable targets are the usual finding here.

  • Documented AI objectives with a measure and a target for each
  • A plan per objective covering actions, resources, owner and deadline
  • The traceability from each objective back to the AI policy
  • Evaluation records showing the objectives were measured

  ISO/IEC 42001:2023, Clause 6.2 — AI objectives and planning to achieve them — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 6.3: Planning of changes [ISO/IEC 42001 (AI management system): own-words representation; Clause 6.3]
  What's needed: When you change the management system itself — new scope, new process, reorganised ownership — do it deliberately: state the purpose, the consequences, the resources, and who is accountable afterwards. Unplanned drift in the system is a nonconformity in its own right, separate from any change to an AI system.

  • A change record for each management-system change, stating purpose and consequences
  • The resource and responsibility decisions taken with each change
  • Approval of the change by the appropriate authority
  • Evidence that affected documentation and processes were updated

  ISO/IEC 42001:2023, Clause 6.3 — Planning of changes — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.1: Resources [ISO/IEC 42001 (AI management system): own-words representation; Clause 7.1]
  What's needed: This is a management action — no tool can perform it for you. Someone has to decide what people, budget, time, tooling and infrastructure the AI management system needs, and then actually provide them. A reviewer tests this by looking for the gap between what your plans require and what was funded.

  • A documented determination of the resources the AI management system needs
  • Evidence the resources were provided — budget approvals, headcount, tooling purchases
  • A record of resource constraints raised and how they were resolved
  • The link from resource decisions back to the AI objectives and risk treatment plan

  ISO/IEC 42001:2023, Clause 7.1 — Resources — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.2: Competence [ISO/IEC 42001 (AI management system): own-words representation; Clause 7.2]
  What's needed: Work out what people whose work affects AI outcomes need to know, check whether they know it, and close the difference through training, hiring or reassignment. Then keep the evidence. Competence claimed but never evaluated is the common gap — a list of courses attended is not an evaluation.

  • A competence definition per AI-relevant role
  • Records of current competence for the people in those roles
  • Training, hiring or mentoring records addressing the gaps found
  • Evidence that competence was evaluated afterwards, not only delivered

  ISO/IEC 42001:2023, Clause 7.2 — Competence — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.3: Awareness [ISO/IEC 42001 (AI management system): own-words representation; Clause 7.3]
  What's needed: This is a management action — no tool can perform it for you. The people doing the work have to know the AI policy exists, understand how their own work affects it, and know what happens if the system is not followed. Awareness is demonstrated by what people can tell a reviewer, not by a completed course.

  • Evidence the AI policy was communicated to the relevant people
  • Awareness material showing each group's contribution to the system and the consequences of not conforming
  • Attendance or acknowledgement records
  • A refresh cycle covering new joiners and role changes

  ISO/IEC 42001:2023, Clause 7.3 — Awareness — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.4: Communication [ISO/IEC 42001 (AI management system): own-words representation; Clause 7.4]
  What's needed: This is a management action — no tool can perform it for you. Decide what you communicate about AI internally and externally, when, to whom, and by what channel — then do it. The typical gap is external communication: buyers, users and affected people are named as audiences but never actually receive anything.

  • A communication plan covering what is communicated about AI, when, to whom and how
  • Named responsibility for each communication
  • Records of communications that actually went out, internal and external
  • Evidence the plan covers the interested parties identified under Clause 4.2

  ISO/IEC 42001:2023, Clause 7.4 — Communication — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.5.1: Documented information — general [ISO/IEC 42001 (AI management system): own-words representation; Clause 7.5.1]
  What's needed: Keep the documentation the standard requires, plus whatever else your system genuinely needs to function. The test is not volume — a reviewer looks at whether the documents a process actually depends on are present, current, and findable by the people who need them. An index listing documents nobody can locate fails this.

  • An index of the documented information the AI management system relies on
  • The documents themselves, current and accessible to the roles that need them
  • A statement of which documents are required by the standard and which you added
  • Evidence documents are findable in practice, not only listed

  ISO/IEC 42001:2023, Clause 7.5.1 — Documented information — general — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.5.2: Creating and updating documented information [ISO/IEC 42001 (AI management system): own-words representation; Clause 7.5.2]
  What's needed: Give documents an identity and a gate: a title, a version, a date, an author, and a review-and-approval step before they take effect. Whatever format you use is fine as long as it is consistent. Documents that change without a version bump are how two teams end up working from different rules.

  • A documentation standard covering identification, format, review and approval
  • Version history for the AI management system's key documents
  • A named reviewer and approver per document
  • Evidence that updates went through the approval step

  ISO/IEC 42001:2023, Clause 7.5.2 — Creating and updating documented information — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 7.5.3: Control of documented information [ISO/IEC 42001 (AI management system): own-words representation; Clause 7.5.3]
  What's needed: Control the lifecycle: who can read each document, who can change it, where it is stored, how long it is kept, and how it is disposed of. Both failure directions matter — a document the right person cannot reach, and a document reachable by people who should not have it.

  • Access rules for the AI management system's documented information
  • Storage and backup arrangements for the documents
  • A retention and disposal schedule
  • Evidence of distribution control, including how superseded versions are withdrawn

  ISO/IEC 42001:2023, Clause 7.5.3 — Control of documented information — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 8.1: Operational planning and control [ISO/IEC 42001 (AI management system): own-words representation; Clause 8.1]
  What's needed: Run the plans rather than hold them. Show the processes that meet your requirements and carry out the Clause 6 actions, show that planned changes went through control, and show that work you outsource — models, data, infrastructure, annotation — is controlled too. Outsourced processes are the half most often left uncovered.

  • Documented operational processes with the criteria they are run against
  • Records showing the processes ran and produced their intended outputs
  • Change-control records for planned operational changes
  • Evidence of control over externally provided processes, products and services

  ISO/IEC 42001:2023, Clause 8.1 — Operational planning and control — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 8.2: AI risk assessment (operational) [ISO/IEC 42001 (AI management system): own-words representation; Clause 8.2]
  What's needed: Actually run the risk assessment on a schedule you have set, and again whenever something significant changes — a new model, a new use case, a new data source, a new market. Keep the dated results. A method defined under Clause 6.1.2 but never executed is the gap this clause exists to catch.

  • A schedule stating the planned assessment intervals
  • The definition of what counts as a significant change triggering reassessment
  • Dated results of the assessments performed
  • Evidence that a real change actually triggered a reassessment

  ISO/IEC 42001:2023, Clause 8.2 — AI risk assessment (operational) — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 8.3: AI risk treatment (operational) [ISO/IEC 42001 (AI management system): own-words representation; Clause 8.3]
  What's needed: Carry out the treatment plan and keep the proof: which control was implemented, when, by whom, and what the residual risk was afterwards. The gap reviewers find is a treatment plan whose items are approved and dated but whose implementation left no trace anywhere in the organization.

  • Implementation records for each item in the risk treatment plan
  • Evidence of the controls operating, not merely being adopted
  • Updated residual-risk positions after treatment
  • Risk-owner acknowledgement of the post-treatment position

  ISO/IEC 42001:2023, Clause 8.3 — AI risk treatment (operational) — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 8.4: AI system impact assessment (operational) [ISO/IEC 42001 (AI management system): own-words representation; Clause 8.4]
  What's needed: Run the impact assessments on your planned schedule and on significant change, and keep the dated results. Because impacts fall on people outside your organization, this is the clause where a stale assessment does the most damage — a system whose use has widened since the last assessment is the case to watch for.

  • A schedule for impact assessments and the change triggers that force one
  • Dated impact-assessment results per AI system
  • Evidence the results reached the risk treatment process
  • A record of a reassessment triggered by an actual change

  ISO/IEC 42001:2023, Clause 8.4 — AI system impact assessment (operational) — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 9.1: Monitoring, measurement, analysis and evaluation [ISO/IEC 42001 (AI management system): own-words representation; Clause 9.1]
  What's needed: Decide what you will monitor about your AI systems and about the management system itself, by what method, how often, and who analyses the result. Then evaluate — data collected but never analysed does not meet this. State how you know the methods produce valid, comparable results rather than noise.

  • A monitoring and measurement plan naming what is measured, how and when
  • The measurement results over at least one full cycle
  • Analysis and evaluation records interpreting those results
  • A statement of why the chosen methods give valid, comparable results

  ISO/IEC 42001:2023, Clause 9.1 — Monitoring, measurement, analysis and evaluation — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 9.2.1: Internal audit — general [ISO/IEC 42001 (AI management system): own-words representation; Clause 9.2.1]
  What's needed: Audit your own AI management system on a schedule, against both the standard's requirements and your own documented arrangements. The point is to find problems before an external assessor does; an internal audit that has never raised a finding usually indicates the audit, not the system, is the problem.

  • Completed internal audit reports covering the AI management system
  • The audit criteria and scope used
  • Findings raised, with corrective actions tracked to closure
  • Evidence the audits covered both the standard's requirements and your own procedures

  ISO/IEC 42001:2023, Clause 9.2.1 — Internal audit — general — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 9.2.2: Internal audit programme [ISO/IEC 42001 (AI management system): own-words representation; Clause 9.2.2]
  What's needed: Build a programme rather than a one-off: frequency, methods, responsibilities, scope and criteria per audit, chosen with regard to how important and how risky each area is. Auditors must not audit their own work — in a small company that usually means an outside pair of hands, and that arrangement should be recorded.

  • A documented internal audit programme with planned frequency and coverage
  • Per-audit criteria and scope definitions
  • Evidence of auditor objectivity and independence from the work audited
  • Records showing results were reported to the relevant management

  ISO/IEC 42001:2023, Clause 9.2.2 — Internal audit programme — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 9.3.1: Management review — general [ISO/IEC 42001 (AI management system): own-words representation; Clause 9.3.1]
  What's needed: This is a management action — no tool can perform it for you. Top management has to sit down at planned intervals and judge whether the AI management system is still suitable, adequate and effective. What a reviewer looks for is a real meeting with real attendees on a real date, not a document titled management review.

  • Minutes of management reviews with dates and attendees
  • Evidence the reviews happen at the planned interval
  • The conclusion reached on continuing suitability, adequacy and effectiveness
  • Evidence that top management, not a delegate, conducted the review

  ISO/IEC 42001:2023, Clause 9.3.1 — Management review — general — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 9.3.2: Management review inputs [ISO/IEC 42001 (AI management system): own-words representation; Clause 9.3.2]
  What's needed: This is a management action — no tool can perform it for you. The review has to be fed the right material: what happened to the actions from last time, what changed internally and externally, how the system performed, what interested parties said, where the risks stand, and what could be improved. A review with no inputs is a meeting, not a review.

  • The input pack presented at each management review
  • Status of the actions from the previous review
  • Performance, audit and risk information included in the pack
  • Interested-party feedback presented at the review

  ISO/IEC 42001:2023, Clause 9.3.2 — Management review inputs — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 9.3.3: Management review results [ISO/IEC 42001 (AI management system): own-words representation; Clause 9.3.3]
  What's needed: This is a management action — no tool can perform it for you. The review has to end in decisions — improvements to make, changes to the system, resources to release — and those decisions have to be recorded with owners and dates. A review that records discussion but no decision leaves nothing to audit against next time.

  • Recorded decisions from each management review
  • Owners and due dates assigned to each decision
  • Evidence decisions were carried out before the next review
  • Any changes made to the AI management system as a result

  ISO/IEC 42001:2023, Clause 9.3.3 — Management review results — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 10.1: Continual improvement [ISO/IEC 42001 (AI management system): own-words representation; Clause 10.1]
  What's needed: Show that the system got better over time and that the improvements came from somewhere — audit findings, incidents, measurement results, review decisions. A list of improvements with no traceable trigger reads as invented; the trigger is what turns an improvement log into evidence.

  • A log of improvements to the AI management system
  • The trigger for each improvement (audit finding, incident, measurement, review decision)
  • Evidence each improvement was implemented
  • An assessment of whether the improvement had the intended effect

  ISO/IEC 42001:2023, Clause 10.1 — Continual improvement — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• Clause 10.2: Nonconformity and corrective action [ISO/IEC 42001 (AI management system): own-words representation; Clause 10.2]
  What's needed: When something does not conform, record it, contain it, work out why it happened, fix the cause rather than the symptom, and check later that the fix held. Keep the record of both the nonconformity and the outcome. Corrective actions closed without an effectiveness check are the most common weakness here.

  • A nonconformity register covering the AI management system
  • Immediate containment actions taken per entry
  • Root-cause analysis and the corrective action chosen
  • Evidence the corrective action was reviewed for effectiveness after the fact

  ISO/IEC 42001:2023, Clause 10.2 — Nonconformity and corrective action — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.2.2: AI policy [ISO/IEC 42001 (AI management system): own-words representation; A.2.2]
  What's needed: Have a written AI policy that states your direction and your commitments for developing or using AI responsibly, approved by someone with the authority to bind the organization. Applies if your organization develops or uses AI at all — in practice that is every organization running an AI management system, so an exclusion here is hard to justify to an auditor. If you conclude otherwise, record the exclusion and the reason in your Statement of Applicability.

  • The approved AI policy document with approver and date
  • Evidence it is published where the people bound by it can read it
  • The commitments it makes, traceable to the requirements you identified
  • Version history showing it is maintained

  ISO/IEC 42001:2023, A.2.2 — AI policy — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.2.3: Alignment with other organizational policies [ISO/IEC 42001 (AI management system): own-words representation; A.2.3]
  What's needed: Check the AI policy against your other policies — privacy, security, quality, acceptable use — and resolve the contradictions rather than letting two documents give opposite instructions. Applies if your organization holds policies other than the AI policy. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • A cross-reference between the AI policy and the related organizational policies
  • A record of conflicts identified and how each was resolved
  • Evidence that related policies were updated where needed
  • A named owner for keeping the set aligned

  ISO/IEC 42001:2023, A.2.3 — Alignment with other organizational policies — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.2.4: Review of the AI policy [ISO/IEC 42001 (AI management system): own-words representation; A.2.4]
  What's needed: Review the AI policy on a set interval and whenever something changes that could make it wrong — new regulation, a new product line, a serious incident. Record the review even when the conclusion is no change. Applies if you maintain an AI policy — which A.2.2 already calls for, so in practice this follows from it and an exclusion would have to explain why. If you conclude otherwise, record the exclusion and the reason in your Statement of Applicability.

  • A defined review interval and the trigger events that force an early review
  • Records of reviews performed, including ones concluding no change
  • Changes made as a result of a review
  • Approval of the reviewed policy

  ISO/IEC 42001:2023, A.2.4 — Review of the AI policy — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.3.2: AI roles and responsibilities [ISO/IEC 42001 (AI management system): own-words representation; A.3.2]
  What's needed: Define who is responsible for what across your AI work and allocate those roles to named people, including the ones nobody volunteers for — risk ownership and incident response. Applies if more than one person is involved in your AI systems. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • A documented allocation of AI roles to named individuals
  • The scope of authority and escalation path for each role
  • Evidence the allocation was communicated and accepted
  • A reassignment record covering staff changes

  ISO/IEC 42001:2023, A.3.2 — AI roles and responsibilities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.3.3: Reporting of concerns [ISO/IEC 42001 (AI management system): own-words representation; A.3.3]
  What's needed: Give people a route to raise a concern about an AI system, and make using it safe — that means a named recipient, a stated response, and protection from retaliation. Applies if any person inside or outside your organization could observe a problem with your AI systems. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • A documented concern-reporting channel and who receives the reports
  • The stated handling process and response commitment
  • Evidence the channel is known to the people who might use it
  • A log of concerns raised and how each was resolved

  ISO/IEC 42001:2023, A.3.3 — Reporting of concerns — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.4.2: Resource documentation [ISO/IEC 42001 (AI management system): own-words representation; A.4.2]
  What's needed: Write down what each AI system depends on to work — data, models, tools, infrastructure, people — so it can be managed rather than discovered during an incident. Applies if you operate one or more AI systems — true of every 42001 candidate, so treat this as near-universal rather than a judgment call. If you conclude otherwise, record the exclusion and the reason in your Statement of Applicability.

  • A resource inventory per AI system covering data, models, tooling, infrastructure and people
  • The lifecycle stage each resource supports
  • A named owner per resource
  • Evidence the inventory is updated when the system changes

  ISO/IEC 42001:2023, A.4.2 — Resource documentation — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.4.3: Data resources [ISO/IEC 42001 (AI management system): own-words representation; A.4.3]
  What's needed: Document the data your AI systems use: what it is, where it came from, on what basis you hold it, and who manages it. Applies if your AI systems use data of any kind, including data supplied with a third-party model — in practice always true for an AI system. If you conclude otherwise, record the exclusion and the reason in your Statement of Applicability.

  • A data inventory covering the datasets used by each AI system
  • The origin and the basis for holding each dataset
  • A named data owner and steward per dataset
  • Evidence of how data resources are updated and retired

  ISO/IEC 42001:2023, A.4.3 — Data resources — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.4.4: Tooling resources [ISO/IEC 42001 (AI management system): own-words representation; A.4.4]
  What's needed: Document the tools and methods used to build, run and maintain AI systems — frameworks, libraries, model-serving stacks, evaluation harnesses, annotation tooling — including their versions. Applies if you use any tooling to build or run AI systems — in practice always true, so an exclusion here is hard to justify. If you conclude otherwise, record the exclusion and the reason in your Statement of Applicability.

  • A tooling inventory with versions, per AI system
  • The purpose each tool serves in the lifecycle
  • Ownership and update responsibility per tool
  • Evidence of how tooling changes are assessed before adoption

  ISO/IEC 42001:2023, A.4.4 — Tooling resources — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.4.5: System and computing resources [ISO/IEC 42001 (AI management system): own-words representation; A.4.5]
  What's needed: Document the compute and system resources your AI systems rely on — training and inference infrastructure, storage, networking — including anything you rent from a provider. Applies if your AI systems run on computing infrastructure of any kind, including infrastructure you rent — in practice always true. If you conclude otherwise, record the exclusion and the reason in your Statement of Applicability.

  • An inventory of computing and system resources per AI system
  • The provider and hosting region for hosted resources
  • Capacity and availability arrangements
  • Evidence of how resource changes are planned and controlled

  ISO/IEC 42001:2023, A.4.5 — System and computing resources — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.4.6: Human resources [ISO/IEC 42001 (AI management system): own-words representation; A.4.6]
  What's needed: Record which people and which skills each AI system needs across its life — who specifies it, builds it, tests it, reviews outputs, oversees it in production, and answers when it goes wrong. Applies if people are involved at any stage of your AI systems’ life cycle — in practice always true. If you conclude otherwise, record the exclusion and the reason in your Statement of Applicability.

  • A record of the human roles and competencies each AI system depends on
  • The lifecycle stage each role covers
  • Evidence the roles are actually filled
  • The plan for coverage when a key person is unavailable

  ISO/IEC 42001:2023, A.4.6 — Human resources — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.2: AI system impact assessment process [ISO/IEC 42001 (AI management system): own-words representation; A.5.2]
  What's needed: Define the process before you need it: when an impact assessment is triggered, who performs it, what it must consider, how severity is judged, and what happens to the findings. Applies if your AI systems can affect people or society. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • A documented impact-assessment procedure with triggers and responsibilities
  • The criteria used to judge severity and likelihood of impact
  • The defined route from findings into risk treatment
  • Evidence the procedure has been applied at least once

  ISO/IEC 42001:2023, A.5.2 — AI system impact assessment process — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.3: Documentation of impact assessments [ISO/IEC 42001 (AI management system): own-words representation; A.5.3]
  What's needed: Keep the completed impact assessments as records — dated, versioned, attributable, and retained for as long as the system runs and afterwards. Buyers and reviewers ask for these directly. Applies if you perform AI system impact assessments. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • Completed impact assessment documents per AI system
  • Date, author and version on each
  • The retention period applied to them
  • Evidence they are retrievable on request

  ISO/IEC 42001:2023, A.5.3 — Documentation of impact assessments — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.4: Assessing impact on individuals or groups [ISO/IEC 42001 (AI management system): own-words representation; A.5.4]
  What's needed: Work out how the system could affect the individuals and groups it touches — including people who never chose to interact with it — across its whole life, not only at launch. Applies if your AI system's outputs can affect people. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • An assessment identifying affected individuals and groups per AI system
  • The types of harm considered and their severity
  • Mitigations chosen and their owners
  • Evidence the assessment covers post-deployment stages, not only design

  ISO/IEC 42001:2023, A.5.4 — Assessing impact on individuals or groups — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.5.5: Assessing societal impacts [ISO/IEC 42001 (AI management system): own-words representation; A.5.5]
  What's needed: Look beyond individuals at the wider effects — on labour, on access to services, on the information environment, on the environment itself — and record what you concluded even where the conclusion is that the effect is small. Applies if your AI system is deployed at a scale or in a domain where societal effects are plausible. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • A societal-impact assessment per AI system in scope
  • The categories of societal effect considered
  • The reasoning where an effect was judged not material
  • Evidence the assessment is revisited as deployment scale changes

  ISO/IEC 42001:2023, A.5.5 — Assessing societal impacts — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.1.2: Objectives for responsible development [ISO/IEC 42001 (AI management system): own-words representation; A.6.1.2]
  What's needed: State what responsible development means for your systems in terms someone can check — fairness expectations, robustness targets, transparency commitments — rather than as values. Applies if your organization develops AI systems. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • Documented responsible-development objectives with measures
  • Traceability from the objectives to the AI policy
  • Evidence the objectives reach the teams doing the development
  • Records showing the objectives were evaluated against actual outcomes

  ISO/IEC 42001:2023, A.6.1.2 — Objectives for responsible development — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.1.3: Processes for responsible design and development [ISO/IEC 42001 (AI management system): own-words representation; A.6.1.3]
  What's needed: Turn those objectives into steps in how you actually build: design review, data checks, evaluation gates, sign-off before release. The process has to be visible in the development workflow, not parallel to it. Applies if your organization designs or develops AI systems. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • Documented design and development procedures for AI systems
  • The gates and approvals built into the workflow
  • Records of the gates being applied to real work
  • Evidence of what happens when a gate is not met

  ISO/IEC 42001:2023, A.6.1.3 — Processes for responsible design and development — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.2.2: AI system requirements and specification [ISO/IEC 42001 (AI management system): own-words representation; A.6.2.2]
  What's needed: Write the requirements down before building: what the system must do, how well, for whom, under what conditions, and what it must not do. Include the responsible-AI expectations alongside the functional ones so they can be tested. Applies if you specify or develop AI systems. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • A requirements specification per AI system, including performance criteria
  • The responsible-AI requirements stated in testable terms
  • The intended purpose and the out-of-scope uses
  • Evidence requirements are baselined and change-controlled

  ISO/IEC 42001:2023, A.6.2.2 — AI system requirements and specification — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.2.3: Documentation of AI system design and development [ISO/IEC 42001 (AI management system): own-words representation; A.6.2.3]
  What's needed: Record the decisions and why they were taken — architecture, model choice, data selection, trade-offs accepted, alternatives rejected. This is the material that answers a reviewer's question about why the system works the way it does. Applies if you design or develop AI systems. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • Design documentation covering architecture and model choices
  • Recorded rationale for the significant decisions and trade-offs
  • The alternatives considered and why they were not chosen
  • Evidence the documentation is updated as the system evolves

  ISO/IEC 42001:2023, A.6.2.3 — Documentation of AI system design and development — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.2.4: AI system verification and validation [ISO/IEC 42001 (AI management system): own-words representation; A.6.2.4]
  What's needed: Test the system against its stated requirements before it goes live and keep testing while it is in use, then keep the results — datasets used, metrics, thresholds, pass or fail, and who signed it off. Applies if you develop or materially configure AI systems. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • Verification and validation plans tied to the stated requirements
  • Test results with datasets, metrics and thresholds recorded
  • Sign-off evidence before release
  • Records of in-life re-testing and what triggered it

  ISO/IEC 42001:2023, A.6.2.4 — AI system verification and validation — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.2.5: AI system deployment [ISO/IEC 42001 (AI management system): own-words representation; A.6.2.5]
  What's needed: Define how a system gets into production: what must be complete first, who authorises it, how it is rolled out, and how it is rolled back. Then show that real releases followed it. Applies if you deploy AI systems into use, including internal use. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • A documented deployment procedure with pre-release criteria
  • A named deployment authoriser per release
  • Deployment records for actual releases
  • The rollback plan and evidence it has been exercised

  ISO/IEC 42001:2023, A.6.2.5 — AI system deployment — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.2.6: AI system operation and monitoring [ISO/IEC 42001 (AI management system): own-words representation; A.6.2.6]
  What's needed: Watch the system in production for the things that actually go wrong — degrading quality, drifting inputs, unexpected use, harmful outputs — with defined thresholds and a named responder. Applies if you operate AI systems in production — in practice always true unless you only build systems that others run, the same provider/operator split that decides A.9.2. If you conclude otherwise, record the exclusion and the reason in your Statement of Applicability.

  • A monitoring plan naming what is watched, the thresholds and the frequency
  • Monitoring output over a representative period
  • The escalation path and named responder for a threshold breach
  • Records of issues detected and how they were handled

  ISO/IEC 42001:2023, A.6.2.6 — AI system operation and monitoring — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.2.7: AI system technical documentation [ISO/IEC 42001 (AI management system): own-words representation; A.6.2.7]
  What's needed: Produce technical documentation that a reviewer outside your team can follow: purpose, design, data, performance, limitations, and known failure modes. Keep it current as the system changes. Applies if any interested party needs technical information about your AI system. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • Technical documentation per AI system, versioned and dated
  • Stated limitations and known failure modes
  • Evidence it is written for the intended audience
  • A process keeping it current with system changes

  ISO/IEC 42001:2023, A.6.2.7 — AI system technical documentation — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.6.2.8: AI system recording of event logs [ISO/IEC 42001 (AI management system): own-words representation; A.6.2.8]
  What's needed: Log what the AI system did — inputs handled, decisions produced, the model version in force, overrides applied — with enough retention and integrity that an investigation months later can reconstruct events. Applies if your AI system's behaviour may need to be traced after the fact. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • A logging specification naming the events captured per AI system
  • The retention period and the protection applied to the logs
  • Evidence logs are actually produced in production
  • A worked example of reconstructing an event from the logs

  ISO/IEC 42001:2023, A.6.2.8 — AI system recording of event logs — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.2: Data for development and enhancement [ISO/IEC 42001 (AI management system): own-words representation; A.7.2]
  What's needed: Define how the data used to build and improve your systems is managed end to end — selection, access, versioning, retention — and who decides. Applies if you use data to develop, train, fine-tune or evaluate AI systems. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • A data management procedure covering the development lifecycle
  • Dataset versioning and access-control records
  • A named owner per dataset used in development
  • Retention and deletion arrangements for development data

  ISO/IEC 42001:2023, A.7.2 — Data for development and enhancement — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.3: Acquisition of data [ISO/IEC 42001 (AI management system): own-words representation; A.7.3]
  What's needed: Control where data comes from and on what terms: the source, the licence or lawful basis, any restrictions on use, and the record proving you may use it the way you do. Applies if you obtain data from any source, including public, purchased, scraped or customer-supplied data. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • An acquisition record per dataset naming the source and the terms
  • The licence, contract or lawful basis permitting your use
  • Any usage restrictions attached to the data, and how they are enforced
  • Evidence of review before a new source is adopted

  ISO/IEC 42001:2023, A.7.3 — Acquisition of data — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.4: Quality of data [ISO/IEC 42001 (AI management system): own-words representation; A.7.4]
  What's needed: Define what fit for purpose means for each dataset — accuracy, completeness, representativeness, currency — and measure against it rather than assuming. Record what you found, including where the data falls short. Applies if data quality affects your AI system's outputs. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • Documented data-quality criteria per dataset
  • Measurement results against those criteria
  • Known quality limitations and their effect on the system
  • Evidence quality is re-checked as data is refreshed

  ISO/IEC 42001:2023, A.7.4 — Quality of data — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.5: Data provenance [ISO/IEC 42001 (AI management system): own-words representation; A.7.5]
  What's needed: Keep the history of your data: where it originated, what happened to it since, which transformations were applied, and which version fed which model. Applies if you use data whose origin or processing history could be questioned. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • Provenance records per dataset covering origin and chain of custody
  • The transformation history applied to the data
  • The mapping from dataset version to model version
  • Evidence provenance is captured at acquisition, not reconstructed later

  ISO/IEC 42001:2023, A.7.5 — Data provenance — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.7.6: Data preparation [ISO/IEC 42001 (AI management system): own-words representation; A.7.6]
  What's needed: Define and record how raw data becomes training or inference data — cleaning, labelling, sampling, splitting, augmentation — because these choices shape the model as much as the algorithm does. Applies if you transform data before it is used by an AI system. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • Documented data preparation procedures per dataset
  • Labelling instructions and quality checks where labelling is used
  • The sampling and splitting approach and its rationale
  • Evidence the preparation steps are reproducible

  ISO/IEC 42001:2023, A.7.6 — Data preparation — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.2: System documentation and information for users [ISO/IEC 42001 (AI management system): own-words representation; A.8.2]
  What's needed: Tell the people using your system what they need to use it properly: what it is for, what it is not for, how well it performs, what it cannot do, and what a human should check. Applies if anyone other than the development team uses your AI system. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • User-facing documentation covering intended use and limitations
  • Stated performance characteristics in terms a user can act on
  • Guidance on human review of the system's outputs
  • Evidence users actually receive the documentation

  ISO/IEC 42001:2023, A.8.2 — System documentation and information for users — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.3: External reporting [ISO/IEC 42001 (AI management system): own-words representation; A.8.3]
  What's needed: Provide a way for people outside the organization to receive relevant information about your AI systems, and decide what you publish and how often. Applies if external interested parties have a legitimate need for information about your AI systems. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • A defined external reporting channel and its audience
  • What is reported and at what frequency
  • Examples of reports actually issued
  • A named owner for external reporting

  ISO/IEC 42001:2023, A.8.3 — External reporting — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.4: Communication of incidents [ISO/IEC 42001 (AI management system): own-words representation; A.8.4]
  What's needed: Decide in advance who you tell when an AI system causes harm or fails badly, within what time, through what channel, and with what content — then be able to show the process ran when something happened. Applies if an AI-system failure could affect anyone outside the team operating it. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • An incident communication procedure naming audiences and timeframes
  • The severity thresholds that trigger external communication
  • Draft or template communications prepared in advance
  • Records of incidents communicated, or a statement that none has occurred

  ISO/IEC 42001:2023, A.8.4 — Communication of incidents — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.8.5: Information for interested parties [ISO/IEC 42001 (AI management system): own-words representation; A.8.5]
  What's needed: Work out what each interested party actually needs to know about your AI systems — buyers, users, affected people, regulators — and make it available to them, rather than publishing one document and hoping it serves everyone. Applies if you identified interested parties with information needs. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • A mapping of interested parties to the information each needs
  • The material provided to each group
  • The channel and frequency for each
  • Evidence the information reached its audience

  ISO/IEC 42001:2023, A.8.5 — Information for interested parties — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.9.2: Processes for responsible use of AI systems [ISO/IEC 42001 (AI management system): own-words representation; A.9.2]
  What's needed: Define how the system may be used once it is live: permitted uses, prohibited ones, where a human must be in the loop, and what a user does when an output looks wrong. Applies if your AI systems are used operationally by anyone — in practice always true once a system is deployed, so an exclusion here is hard to justify. If you conclude otherwise, record the exclusion and the reason in your Statement of Applicability.

  • Documented responsible-use procedures per AI system
  • The stated prohibited uses and the reason for each
  • Human oversight points defined in the workflow
  • Evidence users are trained on and follow the procedures

  ISO/IEC 42001:2023, A.9.2 — Processes for responsible use of AI systems — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.9.3: Objectives for responsible use [ISO/IEC 42001 (AI management system): own-words representation; A.9.3]
  What's needed: State what responsible use is meant to achieve in your setting and how you would know it is happening — override rates, escalation volumes, user-reported problems — so use can be evaluated rather than assumed. Applies if your organization uses AI systems operationally — in practice always true unless you only build systems others run, which is the one case worth stating explicitly. If you conclude otherwise, record the exclusion and the reason in your Statement of Applicability.

  • Documented objectives for responsible use, with measures
  • The measurement approach for each objective
  • Results collected over a representative period
  • Evidence the results influenced how the system is used

  ISO/IEC 42001:2023, A.9.3 — Objectives for responsible use — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.9.4: Intended use of the AI system [ISO/IEC 42001 (AI management system): own-words representation; A.9.4]
  What's needed: Keep actual use inside the purpose and conditions the system was built and tested for, and have a route for handling a request to use it for something else. Drift into unintended use is a common way a well-built system starts causing harm. Applies if your AI systems have a defined intended purpose — in practice always true, since A.6.2.2 requires you to define one. If you conclude otherwise, record the exclusion and the reason in your Statement of Applicability.

  • A stated intended purpose and operating conditions per AI system
  • The process for assessing and approving a new use
  • Monitoring that detects use outside the intended purpose
  • Records of out-of-purpose use identified and how it was handled

  ISO/IEC 42001:2023, A.9.4 — Intended use of the AI system — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.10.2: Allocating responsibilities [ISO/IEC 42001 (AI management system): own-words representation; A.10.2]
  What's needed: Write down who is responsible for what between you and everyone else in the chain — model providers, data suppliers, integrators, customers — so no duty is left assumed to sit with the other party. Applies if any other organization is involved in building, supplying or using your AI systems. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • A responsibility allocation across the AI value chain per system
  • The contractual terms carrying those allocations
  • Identification of duties that no party has accepted, and their resolution
  • Evidence the allocation is revisited when a relationship changes

  ISO/IEC 42001:2023, A.10.2 — Allocating responsibilities — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.10.3: Suppliers [ISO/IEC 42001 (AI management system): own-words representation; A.10.3]
  What's needed: Set requirements for the suppliers whose models, data, tooling or infrastructure sit inside your AI systems, check they meet them before onboarding, and keep checking. A third-party model you cannot get information about is a gap you own. Applies if you use any externally supplied component in your AI systems. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • Documented AI-relevant supplier requirements
  • Assessment records for each supplier before onboarding
  • The contractual terms carrying those requirements
  • Evidence of ongoing supplier monitoring and re-assessment

  ISO/IEC 42001:2023, A.10.3 — Suppliers — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.
• A.10.4: Customers [ISO/IEC 42001 (AI management system): own-words representation; A.10.4]
  What's needed: Give your customers what they need to use your AI system responsibly — its purpose and limits, what they must do on their side, how to report a problem, and what you will tell them when something changes. Applies if you supply AI systems or AI-enabled services to customers. If it does not, record the exclusion and the reason in your Statement of Applicability.

  • Customer-facing documentation covering purpose, limits and customer obligations
  • The support and problem-reporting route offered to customers
  • The change-notification commitment and evidence it is honoured
  • Evidence customers received the material

  ISO/IEC 42001:2023, A.10.4 — Customers — own-words representation · Guidance maintained under our internal review, drawn from the cited article; not legal advice.

Requirements paraphrased in our own words and mapped to ISO/IEC 42001:2023 clause numbering. Not the standard itself — obtain ISO/IEC 42001 from ISO for the authoritative text. DRAFT pending internal review.

What the labels mean

Self-attested

Derived from the company's own answers. Not independently reviewed for this company.

Evidence attached

The company attached its own supporting documents to this self-attested claim. Files are hash-sealed at upload (tamper-evident); their content has not been reviewed by us or anyone else.

Cited to official legal texts

The cited legal text is drawn from the official sources and maintained under our internal review. Whether it applies to this company is automated and not individually reviewed. Not legal advice.

Published 8/28/2026, 8:53:21 PM. This is a point-in-time automated snapshot cited to real legal text; it is not a certification and does not claim compliance. Any item that fails a later freshness check is shown as pending re-verification.