Question Bank

Does your organisation have a documented AI governance policy or charter?

The policy should be formally approved by an executive sponsor, enumerate prohibited AI use cases, assign accountability for AI risk decisions, and specify a review cadence. Absence of a policy is a foundational gap that downstream controls cannot compensate for.

Which of the following topics does your AI governance policy cover?

A mature policy covers all six areas. Policies limited to high-level principles without accountability assignments or prohibited use lists provide weak governance foundations for enterprise buyers.

Are named roles with defined accountability for AI risk management documented and assigned in your organisation?

Diffuse accountability is the most common AI governance failure mode. Look for a RACI or equivalent document that names an executive AI governance sponsor and assigns a system owner to every production AI system.

Which of the following AI governance roles are formally defined and assigned in your organisation?

All five should be present for a mature programme. Missing executive accountability or per-system ownership are the most significant gaps — they indicate AI governance cannot be enforced or audited.

Does your organisation maintain a current inventory of all AI systems in use or under development?

An AI inventory is the prerequisite for proportionate risk treatment. It should cover production, staging, and development systems and be reviewed at least quarterly.

Which of the following fields does your AI system inventory record for each entry?

All six fields should be present. Risk classification and dependency tracking are the most commonly missing fields; without them the inventory cannot drive proportionate risk controls or supply chain oversight.

Has your organisation documented its AI risk tolerance — the types and levels of AI risk it is willing to accept?

Risk tolerance is the decision rule that determines when AI risks require treatment. Without it, risk management decisions are inconsistent and cannot be audited. Look for explicit statements covering safety, fairness, privacy, reliability, and regulatory compliance.

How are your AI risk tolerance statements expressed?

Enterprise buyers should expect at minimum quantified thresholds for the risk dimensions relevant to your AI use cases. Qualitative-only statements cannot be verified or used to drive consistent risk treatment decisions.

Does your organisation apply a documented risk management process to AI systems throughout their lifecycle?

The process should cover risk identification, analysis, evaluation, treatment, and residual risk acceptance. It should be triggered before deployment and after any substantial modification — not only at initial development.

At which points in the AI system lifecycle is a formal risk assessment conducted?

Assessments conducted only at initial deployment miss risk accumulation from model drift, changed use contexts, and regulatory evolution. A mature process triggers reassessment at all five points.

Does your organisation complete a documented impact assessment before deploying an AI system that may affect individuals or groups?

AI impact assessments must go beyond standard risk assessments to address population-scale harms including discrimination, privacy, economic effects, and societal impacts. The assessment should be retained and revisited when system purpose or data inputs change.

Which of the following harm categories does your AI impact assessment explicitly evaluate?

All six categories should be assessed for systems affecting individuals. Missing vulnerable group analysis or societal harm evaluation are common gaps that create regulatory exposure under the EU AI Act and GDPR.

Is the intended purpose, deployment context, and known constraints of each AI system documented and approved before development begins?

Undocumented intent makes post-deployment evaluation and audit impossible. Look for version-controlled design documents that predate development commencement and are approved by the system owner.

Which of the following are recorded in your AI system design documentation before development proceeds?

All six elements should be present for Tier 2+ systems. Socio-technical design decisions (fairness, explainability, safety modes) are most commonly absent from inherited software development practices and represent meaningful governance gaps.

Are defined verification and validation procedures executed before any AI system is deployed or after a substantial modification?

AI V&V must cover dimensions conventional software testing misses: distributional robustness, fairness across population subgroups, and safety failure modes. Testing should not be performed solely by the team that built the system.

Which of the following are included in your AI system V&V testing?

All six elements characterise a mature AI V&V process. Fairness evaluation and independent review are the most frequently absent from programmes that inherit generic software testing practices.

Is a deployment plan with defined gates, rollback procedures, and sign-off required before any AI system enters production?

Ungated AI deployments and modifications are a leading source of production incidents. The deployment plan should require V&V sign-off, impact assessment completion, and a tested rollback procedure before go-live.

Does your AI deployment and change management policy define what constitutes a 'substantial modification' that triggers full pre-deployment controls?

Without a clear definition, teams make inconsistent judgements about whether changes require pre-deployment review. The definition should include examples such as training data source changes, model architecture changes, and inference threshold changes.

Does your organisation maintain a model registry that tracks all ML models in development and production?

A model registry is the prerequisite for tracing production models to their training data and evaluation results — essential for incident response, audit, and debugging. Net-new control: not addressed at this operational level by NIST AI RMF, ISO 42001, or the EU AI Act.

Which of the following are recorded in your model registry for each entry?

All six fields should be present. Missing training dataset references or evaluation metrics at registration time are the most common gaps — they prevent traceability between production behaviour and training decisions.

Is a completed model registry entry required before a model can be promoted from staging to production?

A mandatory promotion gate ensures the registry accurately reflects what is running in production. Registries that are populated after deployment rather than as a gate provide much weaker auditability.

Does your organisation have a documented procedure for decommissioning AI systems?

Retired AI systems that remain partially active — orphaned model endpoints, residual data pipelines — create unmonitored risk. Decommissioning should be a controlled, auditable process with system owner sign-off.

Which of the following steps does your AI system decommissioning procedure require?

All five steps should be present. The most commonly missed is verification of downstream pipeline removal — orphaned integrations calling decommissioned endpoints are a recurring production incident pattern.

Are data used to train, fine-tune, or evaluate AI models subject to documented data management practices covering quality, labelling, and bias?

Training data quality is the single largest determinant of AI system quality. Practices should include documented quality requirements, bias identification steps, and validation before use.

Which of the following training data management practices are applied before model training begins?

All six practices are expected for a mature data governance programme. Missing bias identification or subgroup handling documentation creates exposure to fairness failures that surface after deployment.

Is the provenance of all data used in AI training, fine-tuning, and evaluation documented and traceable?

Provenance records are required for both IP compliance (copyright, licensing) and bias auditing. Data without documented origin cannot be removed from training sets when disputes arise.

What does your training data provenance record include for each data source?

All six elements should be present for sources used in production models. For GPAI providers, copyright compliance mechanisms for web-scraped data are a direct EU AI Act obligation (Art. 53.3).

Does your organisation have documented controls preventing the use of special category personal data in AI training unless a specific legal basis exists?

Special category data (health, biometric, ethnic origin, political opinions, etc.) in training datasets creates significant GDPR and EU AI Act exposure. Processing must have an Art. 9 legal basis and be strictly necessary.

If special category personal data is used in any AI training or evaluation pipeline, which of the following controls are in place?

All applicable controls should be in place. If special category data is not used in any pipeline, answer 'Does not apply' — absence of such data should be confirmed positively, not assumed.

Is technical documentation created before deployment and kept current for each AI system throughout its lifecycle?

Technical documentation is the primary evidence artefact for AI governance audits and regulatory inspections. It must be version-controlled and the current version should correspond to the deployed model version.

Which of the following sections are included in your AI system technical documentation?

All seven sections should be present. 'Known failure modes' and 'human oversight mechanisms' are most commonly absent from inherited software documentation templates and are the sections most scrutinised by enterprise buyers.

Are users of your AI systems informed that they are interacting with an AI before or at the point of first interaction?

Undisclosed AI interaction is deceptive and a regulatory obligation in most jurisdictions. Disclosure must be presented before interaction begins and should not be easily dismissed or hidden.

For AI systems that generate synthetic content (text, images, audio, video), which of the following disclosure mechanisms are in place?

All four mechanisms apply to generative AI systems producing synthetic media. Organisations using AI only for classification or decision-support (not synthetic media generation) should note which apply and which do not.

Is the explainability capability of your AI systems documented, including the type of explanation available and known limits?

Unexplainable AI outputs prevent operators from identifying errors or challenging decisions. Documentation should specify what explanations are available (feature attribution, confidence scores, decision paths) and, where explanation is not technically feasible, state this limitation explicitly.

Which of the following explanation types are available for AI systems that make or inform decisions affecting users?

Organisations must select at least one applicable option. If explainability is not feasible, this must be documented, disclosed to users, and factored into human oversight design — selecting only the final option without strong oversight controls is a risk flag.

Does each production AI system have a defined monitoring plan specifying metrics, alert thresholds, review cadence, and a named monitoring owner?

AI system behaviour degrades in ways not visible from infrastructure metrics alone. Monitoring must include AI-specific measures — confidence score distributions, null or refusal rates, output category distributions — in addition to standard latency and error rate metrics.

Which AI-specific metrics are included in your production monitoring for AI systems?

Mature AI monitoring includes all six. Programmes that monitor only latency and error rates are using generic APM tooling, which misses the behavioural degradation patterns specific to AI systems.

Are deployed AI models evaluated on a scheduled basis for performance degradation and distribution shift (data drift, concept drift)?

Model drift is an AI-specific failure mode with no equivalent in conventional software. Without scheduled evaluation, degraded models operate undetected. Evaluation should use held-out test data or shadow deployments and trigger a documented escalation path when thresholds are breached.

How frequently are your production AI models evaluated for drift or performance degradation?

Frequency should match the velocity of the underlying domain. High-velocity domains (e.g. fraud, content moderation) require monthly or more frequent evaluation. Annual evaluation is insufficient for any system where the data environment changes.

Do your AI systems record event logs capturing inference events, model versions, outputs, confidence scores, and human override events?

AI event logs are the primary forensic artefact when AI-driven decisions are challenged or incidents require root-cause analysis. Logs must be protected from tampering and retained for the period required by applicable regulations.

What is the log retention period applied to your AI system event logs?

EU AI Act deployers are required to retain logs for at least 6 months. The GASP framework recommends 12 months for Tier 2 systems and 24 months for Tier 3. Retention below 6 months is non-compliant for EU AI Act-regulated deployments.

Does your organisation have a documented process for detecting, investigating, and responding to AI system incidents?

A generic IT incident process is not sufficient. The AI incident process must define AI-specific incident types (systematic bias, unsafe outputs, model poisoning), regulatory notification obligations, and post-incident review requirements.

Which of the following are covered in your AI incident response process?

All six areas indicate a mature AI incident response capability. Missing regulatory notification timelines or AI-specific incident categories suggest the organisation is applying a generic IT incident model that will not satisfy EU AI Act Art. 26.4 or Art. 55.3 obligations.

Do AI systems that produce outputs used in decisions affecting individuals have documented human oversight mechanisms proportionate to their risk level?

Human oversight is the last line of defence against harmful AI outputs. It must be substantively designed — not nominal. Oversight persons must have defined competencies, training, and sufficient time to conduct meaningful review.

Which of the following are true of your AI human oversight programme?

All six characteristics indicate substantive oversight. An override rate of 0% over extended periods is a strong signal of nominal (rubber-stamp) oversight rather than genuine review.

Does each production AI system have a tested mechanism allowing authorised operators to override outputs, suspend processing, and fully deactivate the system?

AI systems that cannot be safely stopped or overridden are ungovernable. Override, suspension, and deactivation procedures must be documented, accessible to operators, and tested at least annually — not left to vendor support.

Which of the following override and safe-state capabilities have been tested in the last 12 months for your production AI systems?

All four capabilities should be tested annually. For Tier 3 systems, vendor-independent deactivation is a hard requirement — systems where stopping requires raising a vendor support ticket are not operationally safe.

Does your organisation maintain a documented list of AI use cases that are prohibited?

A prohibited use list translates regulatory red lines (EU AI Act Art. 5) and organisational ethics commitments into concrete guardrails that engineering and product teams can evaluate against during design and launch review.

Which of the following prohibited use categories are explicitly enumerated in your prohibited AI use list?

All seven categories reflect EU AI Act Art. 5.1 prohibited practices. Missing any of these from a documented list is a compliance gap for organisations subject to the EU AI Act.

Do AI systems that score, rank, recommend, or classify individuals have documented fairness objectives with measurable definitions?

Bias cannot be detected without predefined, measurable fairness criteria. Objectives should specify the fairness metric (e.g. demographic parity, equalised odds) and the pass/fail threshold, relative to the system's purpose and affected population.

How is bias testing conducted for AI systems subject to bias risk in your organisation?

All five practices are expected. Bias testing conducted only at deployment without production monitoring misses in-production bias accumulation from feedback loops and data drift.

Are AI systems evaluated for AI-specific security vulnerabilities — such as data poisoning, adversarial examples, and model extraction — as part of your security testing programme?

AI-specific attacks are not detected by conventional SAST/DAST tooling. Evaluation must be explicitly scoped to AI attack classes and conducted separately from standard application security testing.

Which AI-specific attack classes are evaluated in your AI security testing programme?

Coverage of all six attack classes characterises a mature AI security evaluation programme. For GPAI models with systemic risk designation, adversarial testing per standardised protocols is an EU AI Act Art. 55.1 obligation.

Do AI systems that produce outputs acted upon by users or automated processes have defined confidence thresholds, with outputs below threshold triggering a documented fallback?

Net-new control: confidence-gating is a structural quality control unique to probabilistic AI systems, not addressed by existing frameworks at an operational level. Outputs acted upon without confidence validation create uncontrolled downstream risk.

What action is taken when an AI output falls below the defined confidence threshold?

Routing to human review, abstention, or mandatory escalation are all acceptable fallbacks. Silent pass-through of low-confidence outputs is not acceptable for systems where outputs drive consequential decisions.

Do your LLM-based or generative AI systems that produce statements users may rely on as factual have controls in place to detect and limit hallucinated or unverifiable outputs?

Net-new control: hallucination is an intrinsic property of large language models not present in classical software. It requires specific operational controls — existing frameworks do not address this at an actionable level. For safety-critical use cases, additional human verification is required regardless of other controls.

Which hallucination and factual accuracy controls are active for your LLM-based systems?

The control requires at least two active controls from this list. For safety-critical use cases (healthcare, legal, financial decisions), the human verification step is mandatory regardless of what other controls are in place.

Do your LLM-based systems that accept user-supplied or externally-sourced input have documented controls against prompt injection attacks?

Net-new control: prompt injection is an attack class specific to LLM-based systems. Adversarial input can override system instructions, exfiltrate data, or cause the model to take unauthorised actions. It is not covered by conventional SAST/DAST or existing frameworks at an operational level.

Which prompt injection protection controls are active in your LLM-based systems?

At least two controls should be active. For agentic systems with tool access (web browsing, code execution, database queries), privilege separation and tool-call sandboxing are critical — prompt injection in agentic systems can result in unauthorised real-world actions.

Are LLM request-response interactions logged with sufficient detail to support incident investigation and audit?

Net-new control: LLM interaction logs are the primary forensic artefact for investigating misuse, jailbreak attempts, harmful output incidents, and data leakage. No existing framework specifies what these logs must contain for LLM systems.

Which fields are captured in your LLM request-response logs for each interaction?

The first six fields are required for all LLM systems. Full prompt and response logging applies to high-risk applications and must be protected by access controls restricting access to security and operations roles only.

Do your AI systems exposed to external users have mechanisms to detect and respond to misuse attempts, including jailbreak patterns and automated abuse?

Net-new control: public-facing LLM systems face continuous adversarial probing. Misuse detection is an AI-specific operational security control with no equivalent in classical application security and is not addressed operationally by any existing framework.

Which misuse and abuse detection capabilities are active for your public-facing AI systems?

All seven capabilities characterise a mature misuse detection programme. AI-specific rate limits separate from generic API rate limits are commonly absent — shared limits allow targeted LLM abuse to consume a disproportionate share of capacity before triggering generic controls.

Does your organisation perform a documented risk assessment before integrating a third-party AI system, model, or AI-enabled service?

Third-party AI systems introduce risks distinct from conventional software vendor risk: model changes without notice, training data leakage, provider-level safety failures. Assessment should cover data practices, change notification policies, and exit options.

Which of the following dimensions does your third-party AI risk assessment cover?

All seven dimensions are expected for foundation model providers such as LLM APIs. Whether inputs are used for model training is often the most commercially sensitive dimension and should be confirmed in contract terms, not assumed from general documentation.

Do your written agreements with third-party AI providers and downstream AI integrators explicitly allocate compliance responsibilities and define information exchange obligations?

AI supply chain responsibility is uniquely ambiguous: the same model can shift from non-high-risk to high-risk based on how a downstream party deploys it. Contractual clarity is required to prevent responsibility gaps under the EU AI Act.

Which of the following are addressed in your AI supply chain agreements?

All six provisions are expected for agreements covering high-risk AI systems. The obligation covering high-risk reclassification by downstream use is the provision most commonly absent from AI supply chain contracts and represents significant regulatory exposure.

Where your organisation provides an AI system deployed by customers, do you provide customers with written instructions for use covering limitations, oversight guidance, and their regulatory obligations?

SaaS AI providers bear upstream responsibility for enabling customers to govern the AI systems they deploy. Incomplete instructions create downstream governance failures and regulatory exposure for both parties under the EU AI Act.

Which of the following are included in the instructions for use you provide to customer deployers?

All six elements are expected for AI systems deployed in regulated enterprise contexts. Missing DPIA information packs and EU AI Act deployer obligation checklists are the most common gaps — they shift compliance burden onto customers who may lack the technical context to fulfil it.

Are your LLM-based AI systems evaluated for training data extraction risk before deployment and after retraining, using membership inference testing and direct extraction probing?

Net-new control: LLMs can reproduce verbatim training data — including PII, credentials, and copyrighted content — when prompted. This is an AI-specific data leakage vector with no equivalent in conventional data security, not addressed operationally by any existing framework.

Which of the following training data extraction controls are applied to your LLM-based systems?

Membership inference testing and extraction probing are the minimum baseline. Mitigations (output length constraints, PII redaction, differential privacy) are required for any LLM that scores above the documented risk threshold in its evaluation. The risk evaluation methodology and results must be retained.

Does your organisation have a documented secure software development lifecycle (SDLC) policy that defines required security activities at each development phase?

The policy must cover all phases: requirements, design, development, testing, deployment, and maintenance. It should have a named owner, effective date, and defined review cadence.

How frequently is the secure SDLC policy reviewed and updated?

Annual review is the minimum. The policy should be updated whenever there is a significant change in development technology, tooling, or regulatory requirements.

Are information security and privacy requirements formally identified, documented, and approved before development begins on new applications or significant features?

Requirements must be documented before the first development sprint — not derived after implementation. Traceability from requirement to implementation and testing is expected.

How are security requirements derived for new development work?

Requirements derived from threat modelling and risk assessments are most robust. Ad hoc approaches without a defined method introduce inconsistency and gaps.

Has your organisation adopted documented secure coding standards that are communicated to all developers and cover common vulnerability classes?

Standards must be accessible to and used by all developers — not just security specialists. They should reference an industry taxonomy (e.g. OWASP Top 10, CWE Top 25) and be reviewed at least annually.

How are secure coding standards enforced in your development process?

Automated enforcement via SAST in CI is the strongest mechanism. Documentation without enforcement or training provides weak assurance.

Is security testing — including SAST and DAST — integrated into your development and release pipeline with gates that must pass before code is promoted to production?

Security testing must be automated in CI/CD, not performed only before major releases. Blocking gates for critical and high findings are expected.

Which security testing activities are integrated into your development pipeline?

SAST and SCA on every PR are baseline expectations for a mature secure development pipeline. DAST on release candidates and IaC scanning indicate a more comprehensive posture.

Is penetration testing of production systems and applications conducted at least annually by a party independent of the team responsible for the system?

Testing must be performed by a party independent of the development team — either an external firm or a distinct internal red team. Self-assessed or developer-led testing does not satisfy this control.

How are penetration test findings managed after testing is complete?

Every finding must have a corresponding ticket. Critical findings should be remediated and retested within 30 days. Untracked or unconfirmed remediation significantly weakens the value of the pen test.

Does your organisation have a vulnerability management process that identifies, classifies, prioritises, and remediates vulnerabilities on a risk-based schedule with defined SLAs?

The process must include regular scanning (at minimum monthly for internet-exposed systems), defined SLAs by severity, and documented metrics. Ad hoc patching without tracking does not satisfy this control.

What are your defined remediation SLAs for critical-severity vulnerabilities (CVSS ≥ 9.0) in internet-exposed systems?

14–30 days is a widely accepted industry standard for critical findings. SLAs beyond 30 days for critical vulnerabilities in internet-exposed systems represent a significant risk exposure.

Is a software bill of materials (SBOM) or equivalent inventory of third-party dependencies maintained, and are dependencies monitored for known vulnerabilities?

Monitoring must be continuous — not just at the time of initial selection. SCA tooling integrated into CI is the expected mechanism, not periodic manual checks.

Which dependency and patch management practices are in place?

Automated SCA in CI with deployment gates is the baseline expectation. Manual-only processes introduce delays that leave known vulnerabilities unaddressed for extended periods.

Are all secrets — including API keys, database credentials, tokens, and private keys — stored in an approved secrets management system, and is hardcoding secrets in source code or version control prohibited?

Both elements are required: approved vault storage AND an active prohibition on hardcoding. A policy without tooling enforcement (e.g. secret scanning in CI) is insufficient.

Which secrets management controls are in place in your development and deployment environment?

A vault combined with CI-based secret scanning provides both preventative and detective coverage. Secrets logged in a vault with rotation policies indicate a mature posture.

Are all changes to production systems, applications, infrastructure, and configuration subject to a formal change management process including documentation, risk assessment, approval, and rollback procedures?

Every production change — including infrastructure and configuration changes — must have a traceable record. Emergency changes require an expedited but still documented approval, not zero oversight.

How are production changes authorised and deployed in your organisation?

Every production deployment should be traceable to an approved change record. The ability to audit who approved what change, and when, is a key audit expectation.

Are development, test, and production environments logically or physically separated, with distinct access controls and deployment rights for each environment?

Separation must be structural (e.g. separate cloud accounts, VPCs, Kubernetes namespaces) — not solely procedural. Developers with write access to dev/test must not hold equivalent production write access.

Is production data permitted in development or test environments?

Use of production data in non-production environments without de-identification is a data protection risk and a finding in most audit frameworks. Any approved exceptions must have a de-identification record.

Are all externally-exposed and internally significant APIs subject to defined security controls, including authentication, authorisation, rate limiting, and input validation on every endpoint?

Authentication and authorisation must be enforced on every endpoint — unauthenticated routes should be the exception with documented justification, not the default. Sensitive data must not appear in query parameters or error responses.

Which API security controls are implemented in your production environment?

Authentication, object-level authorisation, and rate limiting are the three most impactful controls for preventing the most common API vulnerabilities (OWASP API Top 10).

Are build artefacts (container images, binaries, packages) cryptographically signed, and are signatures verified before deployment to production?

Signing and verification must both be in place and automated. Signing without verification provides no meaningful protection. Unsigned artefacts should be rejected by the deployment pipeline.

Which software integrity controls are in place in your build and deployment pipeline?

Signing plus deployment-time verification is the baseline. Runtime integrity monitoring and SBOM generation indicate a mature supply chain security posture.

Are documented secure architecture and engineering principles — such as defence in depth, fail-secure defaults, and minimal attack surface — formally adopted and applied when designing systems?

The principles must be documented, accessible to engineers, and demonstrably applied in design decisions — not merely stated in a policy document. Architecture decision records (ADRs) are a typical artefact.

How are security architecture principles applied during the design of new systems or significant changes?

A formal design review with a security stakeholder, producing documented architecture decision records (ADRs), is the expected practice for significant systems.

Does your organisation have a publicly accessible vulnerability disclosure programme (VDP) or responsible disclosure policy that defines how external researchers can report security vulnerabilities?

The VDP must be publicly reachable without authentication, include a defined submission channel, scope statement, response timeline commitment, and a safe-harbour clause protecting good-faith researchers.

How is your vulnerability disclosure programme operated?

A formal VDP page with a defined SLA is the minimum. A managed bug bounty programme with scope, triage, and tracking provides stronger coverage. The absence of any disclosure channel leaves reported vulnerabilities without a clear path to resolution.

Does your organisation have a documented Business Continuity Plan (BCP) that identifies critical services, recovery priorities, roles, communication protocols, and escalation paths, reviewed at least annually?

The BCP should be formally approved by senior management, version-controlled, and updated following any significant incident or organisational change.

When was the Business Continuity Plan last formally reviewed and approved?

Annual review is the minimum requirement. A review triggered by a significant incident or major organisational change within the review period also satisfies this requirement.

Does your organisation have a documented Disaster Recovery Plan (DRP) that defines recovery sequences, responsible roles, and technical restoration procedures for critical IT systems and services?

The DRP is distinct from the BCP — it should contain specific technical runbooks for recovering each critical system from backup or failover infrastructure.

What does the Disaster Recovery Plan include?

All six elements are expected in a production-grade DRP. A plan containing only high-level guidance without specific recovery procedures is insufficient for audit purposes.

Are Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) formally defined for each critical service, agreed with business owners, and documented in the BCP and DRP?

RTOs and RPOs must be explicitly defined — not inferred from backup frequency or infrastructure configuration. Each objective should be signed off by a named business owner.

What is the defined RTO for your primary production service in the event of a full service outage?

The RTO should be consistent with contractual availability commitments and validated through DR testing. An undefined RTO indicates a gap in continuity planning.

Are data and system backups performed at a frequency that satisfies the defined RPO, with backups stored off-site or in a separate cloud region, encrypted at rest, and access restricted to authorised personnel?

Backups should cover application data, system state, and configuration. Encryption using a managed KMS key and IAM-restricted access to backup storage are expected.

Which of the following characteristics apply to your production backup implementation?

All six characteristics are expected for a production backup implementation that satisfies RPO commitments and audit requirements.

Is backup restoration tested at least annually to verify that backups are complete, uncorrupted, and recoverable within RTO/RPO targets, with test results documented?

Restoration tests must use actual production backup data, not synthetic test backups. Test results should document measured recovery time and data integrity outcomes.

What was the outcome of the most recent backup restoration test?

A passing test with documented results is the expected outcome. Any failure should trigger remediation before the next test cycle. An untested backup set should be treated as unverified.

Are business continuity and disaster recovery plans exercised at least annually using tabletop exercises, functional tests, or full simulation, with results documented and plans updated accordingly?

Exercises should include personnel with defined response roles. Lessons learned must be captured and result in updates to the BCP, DRP, or related procedures.

What type of BCM/DR exercise was most recently conducted, and when?

A tabletop exercise is the minimum acceptable exercise type. A full simulation or live failover test provides the strongest evidence of plan effectiveness.

Do documented provisions exist for processing critical workloads from an alternate site or cloud region, and are out-of-band communication channels identified and tested for crisis coordination?

Alternate processing provisions must not depend on access to the primary site or primary-site telecommunications. Out-of-band channels (e.g. personal mobile numbers, separate messaging platform) should be verified annually.

Which alternate processing and communication provisions are documented and tested?

All six elements are expected for a robust alternate processing and communications posture. Untested alternate provisions or unverified contact lists are common gaps.

Does your organisation maintain a documented data classification policy that defines sensitivity tiers and handling requirements for each tier?

The policy should define at least three tiers (e.g. Public / Internal / Confidential / Restricted) and specify handling rules for storage, transmission, sharing and disposal at each tier. It must be approved by a named owner and reviewed within the last 12 months.

How are data assets assigned a classification tier?

Automated tooling provides the most reliable coverage at scale. Manual classification by data owners is acceptable for smaller or less dynamic data sets, provided a data inventory confirms consistent application.

Are information assets labelled in accordance with the data classification scheme so that recipients can identify the classification at the point of use?

Labels should be visible on documents, data stores, outputs and transmissions. Automated labelling via DLP or sensitivity label tooling (e.g. Microsoft Purview, Google Workspace) is preferred over purely manual labelling.

Which asset types have classification labels actively applied?

A mature labelling programme covers all major asset types. At minimum, documents, emails and data exports should be labelled. Gaps in cloud storage or database labelling should be noted.

Is all sensitive and confidential data encrypted at rest using an approved algorithm (AES-256 or equivalent) across databases, object storage, file systems and backup media?

Encryption must cover all environments holding sensitive or personal data including production databases, object stores (e.g. S3, Cloud Storage), backup snapshots, and attached volumes. Verify the algorithm meets AES-256 or an equivalent approved standard.

At which layer(s) is encryption at rest applied?

A defence-in-depth approach applies encryption at multiple layers. Field-level encryption for highly sensitive fields (e.g. national IDs, payment data) provides the strongest protection against logical access to the database layer.

Is all data transmitted over networks (internal and external) protected using TLS 1.2 or higher, with unencrypted transmission of sensitive or personal data prohibited?

TLS 1.3 is preferred. TLS 1.0 and 1.1 must be disabled. This applies to all public-facing endpoints and to service-to-service communication within the infrastructure.

What is the minimum TLS version enforced on external-facing endpoints?

TLS 1.2 is the minimum acceptable baseline. TLS 1.3 is strongly preferred. Any answer indicating TLS 1.1 or lower requires a remediation plan.

Does your organisation have a documented cryptographic key management policy that covers the full key lifecycle: generation, storage, rotation, revocation and destruction?

The policy must specify key rotation periods, require keys to be stored separately from the data they protect, restrict and log access to key material, and be approved within the last 24 months.

How are encryption keys managed in your production environment?

Cloud KMS with automatic rotation is the baseline expectation for SaaS environments. Keys managed within the application without separation represent a significant control weakness.

Does your organisation maintain a current Records of Processing Activities (RoPA) or equivalent data inventory documenting all personal data processing with the fields required by GDPR Article 30?

The RoPA must include: processing purposes, data categories, data subject categories, legal basis, retention periods, third-party recipients, cross-border transfers, and applicable safeguards. It should be reviewed and updated at least annually.

How is the data inventory or RoPA maintained?

A dedicated privacy management platform provides the most reliable inventory with automated data flow discovery. Spreadsheet-based inventories are acceptable for smaller organisations but must be kept rigorously up to date.

Does your organisation have a documented policy or procedure requiring that only the minimum personal data necessary for a specific, documented purpose is collected?

The policy should explicitly prohibit collection of personal data without a documented purpose and require review when product capabilities change. It should be approved by the DPO or equivalent authority.

How does your organisation enforce data minimisation and purpose limitation in practice?

A mandatory review gate in the development process (e.g. a privacy design review ticket) is the most effective control. Selecting multiple overlapping mechanisms indicates a mature programme.

Does your organisation maintain documented retention schedules for all data categories, and is data securely deleted or anonymised when retention periods expire?

Retention schedules should be assigned to all personal data categories in the RoPA, with a legal or business justification for each period. Deletion should cover primary storage, backups and replicas.

How is data deletion or anonymisation executed when a retention period expires?

Fully automated deletion across all storage tiers (primary, backup, replica) is the strongest control. Any manual or ad hoc approach must be supported by execution records to demonstrate completeness.

Is a current privacy notice published at or before the point of personal data collection, disclosing all information required by GDPR Articles 13 and 14?

The notice must include: controller identity and contact details, DPO contact (if applicable), processing purposes and legal bases, retention periods, third-party recipients, international transfer mechanisms, and all six data subject rights. It should be dated and reviewed within the last 12 months.

What process ensures the privacy notice remains current when processing activities change?

The notice should be updated proactively when new purposes, new third-party recipients, or changes to data subject rights mechanisms are introduced. Annual review alone is insufficient for rapidly evolving SaaS products.

Where consent is relied upon as the legal basis for processing, does your organisation use a consent management mechanism that records granular, freely given, specific and withdrawable consent?

Consent must be opt-in by default (no pre-ticked boxes). Withdrawal must be as easy as granting consent. Consent records should include timestamp, version, and categories consented to.

How is individual consent recorded and managed?

A consent management platform or a structured database log capturing user ID, timestamp, consent version and categories is required to demonstrate valid consent. Unstructured consent capture cannot satisfy GDPR accountability requirements.

Does your organisation have documented processes and technical mechanisms to fulfil all six GDPR data subject rights (access, rectification, erasure, restriction, portability, objection) within the statutory 30-day timeframe?

Each right should have a documented workflow, identity verification step, and defined internal handoff. A request tracking log must demonstrate requests are actioned within 30 days (or 90 days with documented extension).

Which data subject rights can your organisation fulfil without requiring manual engineering intervention?

Self-service or tooling-assisted fulfilment for access, portability and erasure is the expected standard for mature SaaS products. Rights that require manual engineering effort introduce delay and error risk.

Are privacy and security controls embedded into the design process for new features involving personal data, with a formal review required before deployment?

A privacy-by-design gate (e.g. design review ticket, DPO sign-off) must be completed before any new feature involving personal data is released to production. Default configurations should expose the minimum necessary data.

How are privacy-by-design requirements enforced in the development lifecycle?

A mandatory deployment gate with documented sign-off is the most effective control. Post-deployment review or best-efforts application indicates a significant control gap.

Does your organisation conduct Data Protection Impact Assessments (DPIAs) before initiating processing activities that are likely to result in high risk to individuals, including AI-driven processing, large-scale profiling, or use of new technologies?

DPIAs must be completed before high-risk processing commences. GDPR Article 35 mandates them for systematic profiling, large-scale processing of special category data, and use of new technologies. AI-driven SaaS features frequently meet this threshold.

What triggers a mandatory DPIA in your organisation?

Trigger criteria should align with the ICO or EDPB list of processing operations requiring a DPIA. AI processing, profiling and special category data must be included. Fixed-interval-only DPIAs without activity triggers indicate a control gap.

Does your organisation have a documented personal data breach response procedure that includes a process for notifying the supervisory authority within 72 hours of becoming aware of a qualifying breach?

The procedure must define the 72-hour notification window, include a severity assessment to determine notification obligations, specify the decision authority (DPO), and require an internal breach log for all incidents regardless of threshold.

What does your internal breach register capture for each personal data incident?

A complete breach register is required for GDPR accountability. All incidents should be logged regardless of notification threshold. The register must capture the notification decision with documented justification.

Are all cross-border transfers of personal data to countries without an EU adequacy decision governed by an approved transfer mechanism such as Standard Contractual Clauses (SCCs) or Binding Corporate Rules (BCRs)?

The 2021 EC SCCs must be used for transfers under the GDPR. Pre-2021 SCCs invalidated post-Schrems II are not acceptable. A Transfer Impact Assessment should accompany transfers to high-risk jurisdictions.

Which transfer mechanism(s) does your organisation rely upon for international transfers of personal data?

Most SaaS providers rely on 2021 SCCs for transfers to the US and other non-adequate countries. Sole reliance on Article 49 derogations for routine processing is not permitted under GDPR.

Is sensitive and personal data masked, pseudonymised or replaced with synthetic data in non-production environments (development, staging, test) and in analytics, support tooling and logs?

Production personal data must not appear unmasked in non-production environments or in internal tooling unless there is a documented and DPO-approved exception with appropriate compensating controls.

What approach is used to protect personal data in non-production environments?

Automated masking or exclusive use of synthetic data are the strongest controls. Manual masking without automated enforcement is unreliable. Using production data in non-production environments with access-only controls is not an acceptable substitute for masking.

Does your organisation have technical controls in place to detect and prevent unauthorised exfiltration of sensitive and personal data, including monitoring for anomalous bulk data access or export?

DLP controls should monitor all major egress channels (email, cloud storage, API exports, messaging). Network egress should be restricted by default. Alerts should route to a responsible reviewer.

Which data leakage prevention controls are active in your environment?

A layered approach combining application-level DLP, network egress controls and anomaly detection provides the strongest coverage. At minimum, DLP should cover email and bulk export channels for Confidential and Restricted data.

Has your organisation designated a Data Protection Officer (DPO) where required by GDPR, with the DPO contact details published and notified to the relevant supervisory authority?

A DPO is mandatory where processing is large-scale, involves special categories, or involves systematic monitoring of individuals. The DPO must be independent, report to the highest management level, and cannot be instructed on the exercise of their tasks.

How is the DPO role structured within your organisation?

The DPO must not hold a role that creates a conflict of interest (e.g. CISO, legal counsel for processing decisions, or head of marketing). An external DPO is permitted under GDPR provided independence and access requirements are met.

Does every personal data processing activity in your organisation have a documented lawful basis under GDPR Article 6 (or Article 9 for special categories) recorded in the data inventory or RoPA?

The legal basis must be specific to each processing purpose and disclosed in the privacy notice. Processing without a valid, documented legal basis is unlawful regardless of the technical security measures in place.

Which GDPR Article 6 legal bases does your organisation rely upon for processing personal data?

Legitimate interests requires a documented Legitimate Interests Assessment (LIA). Consent must be backed by a compliant consent management mechanism. This question helps identify whether the appropriate legal bases are in use for the type of processing described.

Does your organisation have processes to ensure that personal data held is accurate and up to date, including a mechanism for data subjects to correct their own information?

Users should be able to update their own core personal data fields (name, email, contact details) directly in the product without requiring a formal request. Corrections should propagate to all systems holding the inaccurate record.

How are inaccurate personal data records identified and corrected?

Self-service correction capability alongside a formal rectification request process provides the strongest coverage. Corrections must propagate to all systems (primary database, downstream systems, backups where applicable) to be effective.

Does your organization have a documented information security policy that has been approved by senior management?

The policy should carry a named approver (e.g. CISO or CEO), an approval date within the last 12 months, and a defined scope statement.

How frequently is your information security policy formally reviewed and re-approved?

ISO 27001 and SOC 2 expect at minimum an annual review. Look for a review record (meeting minutes or a workflow ticket) dated within the required interval.

Are information security roles and responsibilities formally documented and assigned to named individuals or functions?

Look for a roles-and-responsibilities document or RACI that names a security program owner and assigns asset ownership for critical information assets.

Which of the following security ownership roles are formally defined and filled in your organization?

At a minimum, a named security program owner and asset owners for critical systems should be documented and verifiable against the org chart.

Is your information security program sponsored by a named executive who is accountable for its direction and resources?

The sponsor should be a C-level executive or equivalent who is named in the security program documents and receives regular program status updates.

How frequently does senior management formally review the status of the information security program?

Management review meetings should produce documented minutes with security agenda items, attendance records, and action items. Annual is the typical minimum.

Does a formal, documented information security program plan exist that defines scope, objectives, covered domains, and resource allocation?

The program plan should be a living document approved by management, listing all security domains in scope and referencing budget or headcount allocation.

How is progress against the information security program plan reported to management?

A documented status report (quarterly or annually) addressed to or acknowledged by a named executive is the expected evidence.

Does your organization conduct formal information security risk assessments on a defined schedule?

A risk assessment should document threats, vulnerabilities, likelihood, impact, current controls, and treatment decisions, produced by a named assessor.

How often is a full information security risk assessment conducted?

Most frameworks require annual assessment at minimum, plus ad hoc assessment on significant system or business changes.

Does your organization maintain a risk register that records identified risks with likelihood, impact ratings, treatment decisions, and named owners?

The register should be reviewed at defined intervals and reflect the current state of the risk landscape, including treatment status for each open risk.

Does your organization have a formal enterprise risk management program with a documented risk tolerance statement and defined treatment options (accept, mitigate, transfer, avoid)?

The ERM program should be governed by an approved policy that states risk appetite, assigns ownership of risks to named roles, and defines the review cadence.

How are risk acceptance decisions documented and authorized in your organization?

Each accepted risk should have a signed or digitally approved acceptance record that names the approver and states the rationale and review date.

Does your organization maintain a tracked plan of action for open risk findings and control deficiencies, with named owners and target remediation dates?

This may be a plan of action and milestones (POA&M), a remediation tracker, or equivalent — findings from risk assessments and audits should appear in it with current status.

How often is remediation progress against open risk findings reported to management?

Regular management-level reporting (monthly or quarterly) with aging, closure rates, and overdue items is the expected practice.

Does your organization explicitly assess fraud risk, including risks arising from insider threat and misuse of system access, as part of its risk management process?

A fraud risk assessment should document insider threat and access-misuse scenarios with likelihood and impact ratings and link findings to detective and preventive controls.

Which of the following controls has your organization implemented in direct response to identified fraud risk?

The link between the fraud risk assessment findings and the controls designed in response should be documented.

Has your organization identified conflicting duties that could enable fraud or error, and documented required separations or compensating controls?

A segregation of duties (SoD) matrix or conflict register should list role pairs that must not be combined, with compensating controls for any necessary exceptions.

How does your organization verify that SoD conflicts are not present in the live IAM environment?

An IAM export cross-referenced against the SoD conflict matrix, showing no user holds both sides of a conflict, is the expected evidence.

Does your organization maintain a current inventory of applicable legal, regulatory, and contractual information security obligations, with ownership assigned to each?

The inventory should cover obligations across all operating jurisdictions and be reviewed at least annually, with additions made when new contracts or regulations apply.

How frequently is the compliance obligations inventory reviewed and updated?

An annual review that produces a dated record with a named reviewer is the minimum. Updates should be visible whenever new obligations arise mid-year.

Does your organization conduct periodic internal audits or compliance checks of information security controls, with findings reported to management?

An internal audit report should state scope, list findings by severity, include a management response with owners and target dates, and be produced by someone independent of the function audited.

How frequently does your organization conduct information security internal audits?

Most frameworks expect at least annual internal audit activity. Findings should feed directly into the remediation tracker.

Does your organization have a defined continuous monitoring strategy that specifies metrics, frequencies, and responsibilities for monitoring control effectiveness?

The strategy should be documented, management-approved, and reference how monitoring outputs feed into risk register updates — not rely solely on annual audits.

Which of the following continuous monitoring activities are currently operational in your organization?

Evidence should show monitoring outputs (dashboards, scan reports, alert logs) generated at the frequencies defined in the strategy.

Does your organization have a formal process for requesting, approving, and tracking exceptions to information security policies?

The process should require a business justification, named approver, risk acceptance rationale, and a defined maximum exception duration.

How are active policy exceptions tracked and managed?

An exception register should show that no exceptions are past their expiry date without renewal or remediation, and that each carries a named approver.

Does your organization maintain a documented inventory of information assets and processing systems, with designated owners for each asset?

The inventory should include all production systems and critical data stores, show a named owner per asset, and have a last-reviewed date within the defined interval.

How does your organization keep the asset inventory current as assets are added, modified, or decommissioned?

An automated discovery cross-reference or change-management trigger is the most reliable control — the inventory should match live cloud infrastructure within 30 days.

Does your organization maintain a software license inventory that tracks licensed software in use, entitlement counts, and renewal dates?

The inventory should show that usage does not exceed entitlement and that no licenses are operating past expiry.

Does your organization have a documented procedure that prohibits unauthorized software installation and defines how licensing non-compliance is identified and remediated?

The procedure should cover prohibited actions (unauthorized copying, use of unlicensed software), the process for flagging violations, and acknowledgement requirements for personnel.

Does your organization have a documented records retention schedule defining retention periods, storage requirements, and destruction methods for each category of compliance-relevant record?

The schedule should cover audit logs, contracts, incident records, and training records at minimum, with specific retention periods aligned to legal and regulatory obligations.

How are retention policies enforced for your primary storage and logging systems?

Automated retention configuration (e.g. S3 lifecycle policies, Google Vault rules) aligned to the retention schedule is the strongest evidence. Immutability should be enabled for audit logs.

Does your organization maintain documented contacts with relevant regulatory authorities, law enforcement, and security industry groups?

A contacts register should list each relationship, the named internal owner, and a last-reviewed date — covering both regulatory authorities for operating jurisdictions and at least one threat intelligence sharing group.

Which of the following types of external security relationships does your organization actively maintain?

Active membership or subscription (not just registration) is the expected standard — confirm the subscription or membership is current and has a named internal owner.

Does your organization have a defined threat intelligence program that collects, analyses, and disseminates threat intelligence to relevant internal stakeholders?

The program should produce documented intelligence outputs (reports or briefings) on a defined cadence, referencing at least two sources and showing distribution to security, engineering, or risk stakeholders.

How does your organization act on threat intelligence findings to update risk posture or controls?

A traceable link between an intelligence finding and a risk register entry or change ticket is the expected evidence — demonstrating closed-loop action.

Does your organization have a documented process for integrating information security requirements throughout the project lifecycle, including mandatory security reviews before go-live?

The process should define required security activities per project phase and require that findings are resolved or risk-accepted before deployment.

At which stages of a project are security activities formally required?

Pre-launch security sign-off is the minimum — look for completed review checklists with a named security reviewer and documented disposition of findings.

Does your organization undergo independent security assessments (internal audit teams independent of the security function, or external third-party assessors) at defined intervals?

The assessor must be independent of the function being assessed. Reports should be dated within the defined interval and addressed to management.

What form does your most recent independent security assessment take?

A SOC 2 Type II report or ISO 27001 audit provides the strongest third-party assurance for enterprise customers. All options above should include a management response to findings.

Does your organization have a documented audit and assurance policy that defines scope, frequency, independence requirements, and reporting responsibilities for the internal audit function?

The policy should explicitly state that auditors cannot audit their own function, define the reporting line (e.g. to CISO or Audit Committee), and be approved within the last 12 months.

Does your organization produce and approve an annual internal audit plan before the start of each audit year?

The plan should list audit subjects, scheduled dates, assigned independent auditors, and carry approval from the CISO or Audit Committee. Completion status against the plan should be trackable.

Does your organization have a documented data protection policy, approved by management, with a named privacy lead responsible for the privacy program?

The policy should cover lawful basis for processing, data subject rights, breach notification, and applicable regulations (e.g. GDPR, CCPA), and be approved within the last 12 months.

Which of the following privacy program artifacts does your organization currently maintain?

A functioning privacy program requires operational artifacts beyond the policy itself — at minimum a RoPA and a breach notification procedure.

Does your organization define, measure, and report security program metrics (e.g. training completion, vulnerability SLA adherence, incident rates) to management on a defined schedule?

Metrics should be compared against defined targets and show trend data. Reports should be addressed to or acknowledged by a named executive or security committee.

Which of the following security metrics does your organization actively track and report?

A good metrics programme covers at least training completion, vulnerability remediation SLA, and incident rates, with results compared to defined targets each reporting period.

Are operating procedures for critical information processing activities documented, version-controlled, and made available to the personnel who need them?

Each procedure should carry a version number, a named owner, and a last-reviewed date within the defined interval (typically 12 months).

Which of the following critical process areas have documented operating procedures that are actively maintained?

Select all that apply and be prepared to provide the procedure documents with version history. Fewer than three covered areas would be considered a material gap.

Does your organization have a documented acceptable use policy (AUP) that defines permitted and prohibited use of organizational information assets, and is it communicated to all personnel before access is granted?

The AUP should explicitly list prohibited activities, personal use limits, and data protection obligations, and be approved by management within the last 12 months.

How is acknowledgement of the acceptable use policy captured and tracked for all personnel?

A digital acknowledgement export showing 100% (or near-100%) completion for all active staff, with acknowledgement dates, is the standard evidence.

Does your organization's offboarding process require all organizational assets to be returned upon termination, and is completion verified and documented?

Completed offboarding checklists for recent terminations should show device return confirmation (asset tag or serial number), access revocation, and a named verifier.

Are ongoing confidentiality and data protection obligations explicitly stated in employment agreements and acknowledged before employment begins?

Employment agreements should include asset return obligations and post-employment confidentiality clauses, with signed copies retained in the HRIS or document store.

Does your organization have a formal insider threat program that includes defined processes for identifying and responding to insider risk indicators, cross-functional involvement (security, HR, legal), and staff awareness of reporting channels?

The program policy should be co-approved by at least two of: security, HR, and legal. It should list both behavioral and technical indicators and define an escalation path.

Which of the following insider threat detection and response capabilities does your organization currently have in place?

Evidence should show the program is operational — at minimum, one active detection capability and at least one cross-functional review or case record in the last 12 months.

Does your organization have a documented personnel security policy covering pre-employment screening, employment security obligations, and termination requirements?

The policy should span the full employment lifecycle — from background screening before hire through to offboarding obligations — and be approved and communicated to all staff.

How do you confirm all personnel have received and acknowledged the personnel security policy?

An acknowledgement export showing all active employees with a recorded acknowledgement date at or before their first day of system access is the expected evidence.

Does your organization conduct background screening on all candidates before system access is granted, proportional to the sensitivity of the role?

Screening should be completed before access provisioning. The scope of the check should match a defined role risk tier (identity, employment history, criminal record, etc.).

Which of the following personnel categories are subject to pre-employment background screening in your organization?

ISO 27001 and most enterprise customer requirements expect screening for contractors and third parties with privileged access, not just direct employees.

Is background screening completion documented and traceable, confirming the check was completed before the individual's first system access date?

Screening completion certificates or provider pass/fail records should be on file, with a completion date that pre-dates the access provisioning date.

Do your employment agreements contain explicit information security obligations, confidentiality requirements, and acknowledgement of organizational security policies?

Obligations should be stated in the agreement itself, not just referenced by pointer. Signed copies should be on file and the agreement should be signed before or on the first day of employment.

When security obligations in employment agreements change materially, how does your organization ensure affected personnel acknowledge the updated terms?

A change notification record and re-acknowledgement log showing all affected employees confirmed updated terms within a defined period is the expected evidence.

Do all personnel complete a security awareness training programme at onboarding and at least annually thereafter, with completion tracked and reported?

Training records from the LMS or awareness platform should show completion rates at or above the defined target (typically 95%+), with new hires completing within 30 days of their start date.

Which of the following topics are included in your annual security awareness training curriculum?

At minimum, phishing awareness, acceptable use, incident reporting, and privacy obligations should be covered. Training content should be updated to reflect the current threat landscape.

Does your organization evaluate the effectiveness of its security awareness programme (e.g. through phishing simulations, quiz scores, or click rate trends)?

Phishing simulation results showing click rate trends over the year, with curriculum changes triggered by high-risk cohorts, demonstrate programme effectiveness.

Do personnel in elevated-privilege or security-critical roles (e.g. sysadmins, developers, incident responders) receive role-specific security training before gaining production access and at defined intervals thereafter?

Role-based training records should show completion before or within 30 days of production access being granted, with annual renewal records on file.

Which of the following role-specific security training tracks does your organization deliver?

At least three distinct role tracks covering different privilege tiers are expected. Training should be matched to the specific systems and data each role can access.

Does your organization have a formal, documented disciplinary process that covers information security policy violations and is communicated to all personnel?

The process should define tiered consequences proportionate to severity, require investigation before sanctions are applied, and include an appeal mechanism.

Can your organization provide evidence (e.g. anonymized case records or a management attestation) that the disciplinary process has been applied to a security policy violation in the last 12 months?

The existence of a process is insufficient on its own — evidence of either use or a credible attestation of non-use demonstrates the process is known and active.

Does your organization revoke all logical access rights for terminated employees and contractors within a defined timeframe, using a documented offboarding process?

Completed offboarding checklists should show access revocation dates and confirm the SLA was met (typically same-day for involuntary terminations).

What is your defined maximum timeframe for revoking all logical access after an involuntary termination?

Same-day revocation for involuntary terminations is the expected standard. IAM export cross-referenced against the HR termination log is the verification evidence.

Does your offboarding process explicitly cover contractors and third-party personnel, not just direct employees?

Contractor and third-party access revocation should follow the same SLA and checklist as direct employees. Service accounts associated with contractors should also be disabled or re-owned.

Does your organization have documented security requirements for remote working, covering device security, network access, information handling, and incident reporting?

The policy should specify MDM enrollment or equivalent device controls, VPN or zero-trust network access requirements, and a process for reporting lost or stolen devices.

How are remote working security requirements communicated to and acknowledged by remote workers?

All employees with a remote or hybrid arrangement should have a current acknowledgement on file, pre-dating or concurrent with the start of their remote working arrangement.

Do all personnel have access to a clearly communicated, easy-to-use mechanism for reporting observed or suspected security events, and are they trained on when and how to use it?

At least two reporting channels should be defined (e.g. email alias, Slack channel, ticketing form) and included in security awareness training. A non-retaliation statement should be present.

How frequently are the security event reporting channels tested to confirm they are operational?

Channel testing (e.g. a test submission verified to have been received and acknowledged) should produce a dated test record. Reports received via the channel should be acknowledged within a defined SLA.

Are information security roles and responsibilities formally defined for all positions, specifying data access entitlements and accountability obligations, and communicated to personnel?

Job descriptions or role definition documents should include a security responsibilities section covering systems in scope, data access entitlements, and asset accountability for elevated-access roles.

Does your organization have a process for updating role security responsibilities when a role changes, and for ensuring personnel are informed of the updated obligations?

The process should define who owns role definition maintenance, what triggers an update (role change, new system access), and how updated responsibilities are communicated to affected personnel.

Does your organisation have a documented access control policy that defines rules for granting, reviewing, and revoking access?

The policy should be version-controlled, have a named owner, and include explicit least-privilege and need-to-know requirements. An undocumented or informal approach does not satisfy this control.

How frequently is the access control policy reviewed and re-approved?

Annual review is the minimum acceptable cadence. The policy must be re-approved by a named owner after each review.

Is a centralised inventory of all identities — including human users, service accounts, and other non-human identities — maintained?

The inventory should be sourced from the IdP or IAM platform (e.g. Okta, Azure AD, AWS IAM), not maintained only in a spreadsheet. It must include both human and non-human identities.

Are shared or generic accounts in use in any of your production systems?

Shared accounts undermine audit trail integrity. Any active shared accounts must have a documented justification and a named individual accountable for activity on that account.

Are formal, documented processes in place for provisioning and deprovisioning user accounts, including required approvals before access is granted?

Provisioning should require at minimum one named approver distinct from the requester. Approvals must be recorded in a ticketing or workflow system.

When an employee leaves or changes role, within what timeframe are their accounts disabled or access updated?

Same-day or next-business-day deprovisioning is best practice. Delays beyond 3 days create significant orphaned-access risk. The timeframe should be defined in policy and verifiable from logs.

Are access rights for all users formally reviewed and revalidated on a defined periodic schedule?

Reviews must be documented, include a named reviewer per access entry, and result in revocation of any access no longer required. Ad hoc or informal reviews do not satisfy this control.

How frequently are access reviews (recertification campaigns) conducted?

Annual is the minimum; more frequent reviews are expected for privileged accounts and sensitive systems. Reviews should be triggered in addition to scheduled cycles when users change roles.

Is the principle of least privilege enforced so that users and services are granted only the minimum access needed for their current function?

Enforcement requires that roles are scoped tightly and that access is actively reviewed when responsibilities change — not merely that a policy document states the principle.

How is least-privilege enforcement implemented in your environment?

Multiple mechanisms in combination indicate a mature least-privilege posture. Relying solely on a written policy without technical enforcement is insufficient.

Is access to systems and data assigned through defined roles rather than granted directly to individual users?

Role-based assignment must be the default. Direct individual-level grants should be exceptions with documented justification, not the norm.

Are separation-of-duties (SoD) conflicts — where a single user could both initiate and approve a sensitive operation — formally identified and prevented?

Technical prevention (e.g. an IGA tool blocking conflicting role assignments) is stronger than procedural controls alone. Any unmitigated SoD conflict in a sensitive function should be documented with a compensating control.

Is an inventory of all privileged accounts (administrative, root, superuser, and equivalent) maintained and tightly controlled?

Every privileged account must map to a named individual with a documented business justification. Shared admin accounts are not acceptable.

Which controls are applied specifically to privileged accounts in your environment?

MFA and full audit logging are non-negotiable minimums. JIT access and PAM tooling represent a mature privileged access posture.

Is MFA enforced for all user access to externally-facing systems, administrative interfaces, and systems holding sensitive or regulated data?

MFA must be enforced at the system or IdP level, not left to user discretion. Enforcement means no in-scope access path can be completed with a password alone.

Which MFA methods are supported and in use for accessing in-scope systems?

Hardware keys and authenticator apps are phishing-resistant and preferred. SMS and email OTP are weaker but acceptable as supplementary factors. SMS-only is not considered strong MFA for high-risk access paths.

Is a credential management policy in place that defines minimum password complexity, rotation schedules, prohibition of credential reuse, and approved storage mechanisms?

The policy must be enforced at the system level, not just documented. Key settings to confirm: minimum length ≥12 characters, reuse prohibition, and approved hashing/storage for secrets.

How are API keys, tokens, and service credentials stored?

A dedicated secrets vault with access control and audit logging is the expected approach. Credentials committed to version control — even encrypted — represent a significant risk. Plaintext storage in version control is a critical finding.

Are service accounts, API keys, and other non-human identities inventoried and managed with a documented owner, defined access scope, and rotation or expiry policy?

Every non-human identity should have a named team or individual as owner. Unowned or undocumented service accounts are a significant risk. The inventory must be kept current — not just created once.

How frequently are API keys and service account credentials rotated?

Automated rotation is strongly preferred. Long-lived, non-rotating credentials significantly increase the impact of a credential exposure. Rotation should also occur immediately upon any suspected compromise.

Is remote access to internal systems and infrastructure limited to approved, documented access paths (e.g. VPN or zero-trust network access)?

Direct SSH, RDP, or API access from the internet to internal resources without a sanctioned gateway should be blocked. All remote access paths must be reviewed and reauthorised periodically.

What remote access technology is in use for accessing internal systems?

ZTNA or MFA-enforced VPN are the expected approaches. Direct public internet access to internal systems without an authenticated gateway is a critical finding.

Are session management controls enforced, including idle timeout, absolute session lifetime limits, and session identifier protection?

Controls must be enforced at the system level — not left to the end user to configure. Session identifiers must not appear in URLs and must be invalidated upon logout.

What is the maximum idle session timeout configured for users accessing production systems?

15–30 minutes is the expected range for production and administrative systems. Timeouts above 60 minutes or no timeout configured are findings for sensitive environments.

Are authentication systems configured to lock out or rate-limit accounts after a defined number of consecutive failed login attempts?

The mechanism must be enforced at the system level. The lockout threshold, duration, and recovery process should be defined in policy and verifiable in system configuration.

What mechanism is used to respond to repeated failed authentication attempts?

At least one technical mechanism should be in place at the system or gateway level. Layering multiple mechanisms (e.g. lockout plus IP rate-limiting plus alerting) provides stronger defence against credential stuffing.

Is access to source code repositories, build pipelines, and deployment tooling restricted to authorised personnel with write and merge access requiring explicit approval?

Access to production branches should be restricted with branch protection rules. Write or admin access must require explicit approval and be regularly reviewed.

Which controls are enforced on your production or main branch in source control?

Disabling direct push and requiring at least one reviewer are baseline expectations. Locking branch protection to prevent admin override is a strong additional control.

Does your organisation have a documented Incident Response Plan (IRP) covering roles and responsibilities, communication channels, escalation paths, and coordination with legal, regulatory, and PR functions, reviewed at least annually?

The IRP should be approved by the CISO or equivalent senior owner, version-controlled, and updated following significant incidents. A plan that has not been reviewed in over 12 months is considered stale.

Which functions are explicitly covered in your Incident Response Plan?

All six are expected in a mature IRP. Missing legal or regulatory escalation paths are a common gap that creates exposure during actual incidents.

Are processes and technical controls in place to detect potential security incidents from multiple sources — including automated monitoring alerts, internal reports, threat intelligence, and third-party notifications — with triage decisions documented?

Detection capability should not rely solely on automated alerting. Internal reporting channels and mechanisms to receive third-party notifications are also required.

Which incident detection sources are covered by your triage process?

Automated alerts alone are insufficient. A robust detection process includes internal reporting channels and the ability to receive and triage external notifications.

Are incidents classified by severity and type using a defined taxonomy, with classification criteria documented and consistently applied to determine escalation paths, notification requirements, and response SLAs?

The classification matrix should explicitly include criteria for identifying a personal data breach (triggering GDPR notification obligations) and should be referenced in all incident triage processes.

How many severity levels are defined in your incident classification taxonomy?

Four distinct severity levels with explicit classification criteria and SLAs per level is the expected standard for enterprise SaaS providers. Fewer levels reduce classification precision.

Do documented containment procedures exist for common incident types, with containment actions taken within defined timeframes by severity, and eradication steps logged before recovery begins?

Containment procedures should be specific and actionable — not generic guidance. At minimum, runbooks should exist for account compromise, malware, and data exfiltration incident types.

Which incident types have documented containment and eradication runbooks?

Account compromise, malware, and data exfiltration are the minimum required runbooks. AI-specific incident types are expected for organisations deploying AI systems in production.

Are internal incident reporting requirements and timelines defined for all severity levels, and is there a documented process for notifying the relevant supervisory authority within 72 hours in the event of a personal data breach, as required by GDPR Article 33?

The breach notification procedure must explicitly state the 72-hour GDPR Art.33 obligation and include GDPR Art.33(3) content requirements as a checklist. The procedure should be approved by the DPO or legal team.

Which elements are included in your breach notification procedure?

All six elements are required for a GDPR-compliant breach notification procedure. Missing Art.33(3) content requirements or a defined trigger for data subject notification are common gaps.

Does your organisation have a documented process for notifying affected customers of security incidents that impact the confidentiality, integrity, or availability of their data or service, with defined timelines and required notification content?

Customer notification timelines are often defined in enterprise contracts at shorter intervals than regulatory requirements. The procedure should reference contractual obligations and include approved communication templates.

What is the standard customer notification timeline for a confirmed high-severity security incident affecting customer data?

Many enterprise contracts specify 24–72 hour notification timelines. A defined standard timeline shorter than or equal to the contractual obligation is the expected answer.

Are procedures in place to identify, collect, and preserve digital evidence related to security incidents in a manner that maintains chain of custody and supports potential legal proceedings?

Evidence collection procedures should specify approved tools, chain of custody requirements, storage location, access controls, and retention period aligned to legal and regulatory requirements.

Which elements are included in your evidence collection and preservation procedure?

Chain of custody and secure storage are the minimum requirements. Cloud-based evidence collection procedures are essential for SaaS incident response.

Is a post-incident review conducted following every significant incident, producing documented root cause analysis, corrective action recommendations, and tracked remediation that feeds back into the Incident Response Plan?

Post-incident reviews should be conducted within a defined timeframe after the incident is closed (e.g. within 5 business days for high-severity incidents). Corrective actions must be assigned to named owners with due dates.

What is the defined timeframe for completing a post-incident review following a high-severity security incident?

5 business days is a widely accepted target for high-severity incidents. Reviews conducted more than 30 days after closure risk losing context and reducing the quality of root cause analysis.

Do personnel with incident response roles receive training at onboarding and at a defined periodic frequency, and is the Incident Response Plan tested through tabletop exercises or simulations at least annually?

Training completion should be tracked in an LMS or equivalent system. Exercise results should be used to update IRP procedures — a plan that generates no updates after an exercise likely was not tested meaningfully.

How frequently is incident response training conducted for personnel with defined IR roles?

At onboarding plus annual refresher training is the minimum expectation. Six-monthly training is considered a strong practice for teams with active response responsibilities.

Is up-to-date contact information maintained for relevant regulatory authorities, law enforcement, national CERTs, cloud providers, and legal counsel, with contacts accessible to the IR team and verified at least annually?

The contact list must be accessible without requiring access to primary production systems — it should be stored out-of-band (e.g. printed copy, offline document, or separate communications platform).

Which external contact categories are included in your maintained IR contact list?

Supervisory authority, national CERT, cloud provider security contact, and legal counsel are the minimum required categories. Insurance and DFIR retainer contacts are expected for mature IR programmes.

Does your organisation maintain a documented security baseline governing the configuration of all production cloud services, covering identity, access, network, encryption, and logging settings?

The baseline should be version-controlled, formally approved, and reference a named standard such as CIS Benchmarks or your cloud provider's security foundations.

How are configuration deviations from the cloud security baseline detected and remediated?

Automated CSPM or policy-as-code enforcement provides continuous detection; manual audits are acceptable only if run quarterly or more frequently with documented findings and owners.

Are all production systems (operating systems, containers, hypervisors, and cloud services) deployed against a documented hardening baseline that disables unused ports, protocols, services, and default accounts?

The baseline should reference a named benchmark (e.g. CIS Level 1/2, DISA STIG) and apply to all production workload types, not just servers.

Which approach is used to enforce the hardening baseline and detect deviations?

Automated enforcement at build time combined with runtime drift detection provides the strongest assurance. Periodic scans are a minimum acceptable approach.

Is an accurate, maintained inventory of all production system components kept, capturing component type, owner, environment, and version?

The inventory should cover servers, containers, virtual machines, cloud resources, and network devices. Cloud-native discovery tools or a CMDB are the expected mechanisms.

How frequently is the production asset inventory reconciled against actual deployed resources?

Continuous or weekly automated reconciliation is preferred. Quarterly is the minimum acceptable frequency for a controlled environment.

Are production systems logically isolated from development, test, and administrative networks, and are tenant workloads separated from one another at the network layer?

Isolation should be enforced via VPC boundaries, security groups, network ACLs, or equivalent cloud-native controls — not only by naming convention or access policy.

Which mechanisms are used to enforce network segmentation between environments and between tenants?

Multiple enforcement layers are expected for a strong segmentation posture. At minimum, expect separate network boundaries and explicit deny rules for cross-environment traffic.

Is your production network architecture documented, including trust zones, data flows, and perimeter boundaries, and are defence-in-depth controls deployed at network boundaries?

Documentation should include current data flow diagrams and a network diagram showing trust zones. Defence controls should include at minimum a firewall or WAF and egress filtering.

Which network defence controls are deployed at production network boundaries?

A WAF and egress filtering are baseline expectations for a SaaS provider. IDS/IPS and DDoS protection indicate a more mature defence-in-depth posture.

Is all data in transit across public or untrusted networks protected using TLS 1.2 or later, with deprecated cipher suites disabled?

This applies to all production-facing endpoints: APIs, web interfaces, inter-service communication, and webhook delivery. TLS 1.0 and 1.1 must be rejected.

How is the TLS configuration of production endpoints reviewed and kept current?

Automated scanning on each deployment is the preferred approach. At minimum, a full TLS scan should occur annually and after any change to load balancer, API gateway, or certificate configuration.

Is a vulnerability management programme in place covering authenticated scanning of production systems at least monthly, risk-based prioritisation using CVSS or equivalent, and SLA-bound remediation by severity?

The programme should cover both infrastructure and application layers. Scan credentials should be verified — unauthenticated scans miss a significant portion of findings.

What is the defined SLA for remediating critical severity vulnerabilities (CVSS 9.0 and above) in production systems?

Industry expectation for critical vulnerabilities is 7–14 days. 30 days is the acceptable outer limit only when compensating controls are documented for the gap period.

Which tooling is used for authenticated vulnerability scanning of production systems?

Any reputable authenticated scanner is acceptable. The key requirement is that scans are authenticated and cover all in-scope production systems, not just public-facing endpoints.

Are security patches applied to all production systems within defined SLA timelines based on severity, with tracked remediation and documented compensating controls for exceptions?

A formal patch management policy should define timelines per severity band (critical, high, medium, low) and include an emergency patching process for zero-day or actively exploited vulnerabilities.

What is the defined patching SLA for high severity patches (CVSS 7.0–8.9) in production systems?

30 days is the widely accepted baseline for high severity patches. 14 days is considered strong practice. Anything beyond 30 days requires documented compensating controls.

Are managed endpoints and production workloads protected by EDR or anti-malware tooling with up-to-date signatures or behavioural detection, and is unauthorised software installation prevented or detected?

EDR deployment should cover all managed endpoints and, where applicable, production compute workloads. Behavioural detection (EDR) is preferred over signature-only anti-malware.

Which endpoint and workload protection tooling is deployed across production systems and managed endpoints?

A modern EDR agent covering all managed endpoints and host-based firewall enforcement are the minimum expected controls for a SaaS provider.

Is outbound web access from production systems and corporate devices filtered to restrict access to malicious or unauthorised external destinations?

Web filtering should block known malicious categories and command-and-control infrastructure. Egress filtering policies should be documented and applied to both production and corporate traffic.

Which technology is used to enforce web filtering and egress controls?

A cloud-delivered Secure Web Gateway or DNS-based filtering provides the broadest coverage for distributed and remote workforces. Network-layer egress rules are acceptable for production infrastructure.

Is independent penetration testing of production systems, APIs, and infrastructure conducted at least annually and after significant architectural changes?

Testing must be conducted by an independent party — either an external firm or an internal red team independent from the systems under test. The test report should be available on request.

Which of the following best describes the scope and approach of your most recent penetration test?

A full-scope external test is the gold standard. At minimum, production APIs and public-facing web applications should be in scope. Bug bounty alone does not satisfy this requirement.

Is current and projected resource utilisation (compute, storage, network, and API throughput) monitored against defined thresholds, with alerts configured before exhaustion conditions occur?

Monitoring should cover all critical resource types. Alerts should fire with enough lead time to allow scaling decisions before service is impacted.

How frequently is capacity planning reviewed to ensure production infrastructure can meet operational demands?

Auto-scaling removes much of the risk but does not eliminate the need for capacity planning at the service limit level. Quarterly reviews are a minimum for services with defined availability SLAs.

Is production infrastructure deployed with redundancy that eliminates single points of failure for critical components, with availability architecture documented and aligned to RTO/RPO targets?

For cloud-native SaaS, multi-AZ deployment for all critical components (compute, database, load balancer) is the minimum expected redundancy posture.

What level of infrastructure redundancy is implemented for production services?

Multi-AZ within a single region is the baseline expectation. Multi-region is expected where SLAs commit to recovery times that a single-region failure would breach.

Do all production systems synchronise their clocks from approved, authoritative NTP sources, with clock drift monitored and corrected?

Cloud-native environments should use the cloud provider's time sync service (e.g. Amazon Time Sync Service, Google Time Servers). Drift monitoring should alert on offsets exceeding a defined threshold.

How is NTP synchronisation and clock drift monitored across production systems?

Automated drift monitoring with alerts is expected for environments where log correlation accuracy is required for compliance or incident response. Cloud provider defaults alone are insufficient.

Are security-relevant events defined and logged across all production systems, applications, and cloud services, including authentication, privilege use, administrative actions, data access, configuration changes, and system errors?

Log scope should be documented in a formal policy or standard. Gaps in event categories (e.g. no data access logging) are a common audit finding.

Which event categories are captured in your production audit logs?

All seven categories are expected for a complete audit logging posture. Missing data access or configuration change logging are the most common gaps in enterprise SaaS environments.

Are audit logs stored in a tamper-resistant or write-once store, separate from the systems being logged, with unauthorised modification or deletion prevented and alerted?

Log storage should be in a separate account, project, or cloud resource from the systems generating logs. Object Lock (Compliance mode) or equivalent immutability should be enforced.

Which mechanisms are used to protect audit log integrity?

A robust posture combines immutable storage, integrity validation, separation from production accounts, and alerting on access attempts. All five controls together are the expected standard.

Are audit logs retained for a minimum period meeting regulatory and contractual requirements, with retention periods documented and enforced through automated policy?

The minimum expected retention is 12 months online and up to 24 months in cold storage. Retention policies should be automated, not dependent on manual archiving.

What is the current minimum retention period for audit logs in your environment?

12 months online with extended cold storage is the standard expectation. For organisations subject to the EU AI Act or GDPR enforcement, ensure retention aligns to applicable regulatory timelines.

Is log data from all production systems, applications, cloud services, and network devices aggregated into a centralised log management or SIEM platform with search, correlation, and reporting capability?

Centralised collection is a prerequisite for effective threat detection. Siloed logs that cannot be correlated across systems leave blind spots in incident investigation.

Which SIEM or centralised log management platform is in use?

The specific platform is less important than coverage. Any production-grade platform is acceptable provided it ingests all in-scope log sources and has active monitoring.

Are production systems monitored for anomalous behaviour and indicators of compromise, with alerts generated for defined threat scenarios and reviewed within defined SLAs?

Active monitoring requires both configured detection rules and a team responsible for reviewing and responding to alerts. Logs without active review provide no detection capability.

Which threat scenarios are covered by active detection rules in your SIEM or monitoring platform?

The first four categories are minimum expected coverage for a SaaS provider. All seven indicate a mature detection programme.

What is the defined SLA for acknowledging and triaging high severity security monitoring alerts?

24/7 coverage with a 1-hour or faster acknowledgement SLA is the expectation for high severity alerts in a production environment.

Is sufficient log storage capacity provisioned to retain logs for the required retention period without loss, with capacity thresholds monitored and logging pipeline failures alerted promptly?

Silent log loss under storage pressure is a common gap. Capacity monitoring must alert early enough to allow remediation before any log loss occurs.

How are logging pipeline failures and log storage capacity issues detected and responded to?

Automated alerting with a defined response SLA and runbook is the expected standard. Any pipeline failure without an alert and response process represents a gap in logging integrity.

Is a documented continuous monitoring strategy in place that defines the metrics, frequencies, and automated checks monitored across production systems, with results reported to accountable owners at defined intervals?

The strategy should enumerate in-scope metrics, monitoring frequencies, and the reporting cadence. It should be formally approved and reviewed at least annually.

Which elements are included in your continuous monitoring programme?

A mature programme includes all six elements. Configuration compliance and vulnerability scan scheduling are the minimum expected components.

Does your organisation conduct a documented risk assessment of all third-party vendors before engagement, covering security posture, privacy practices, and regulatory compliance?

The assessment should be completed before the vendor is engaged and produce a documented risk rating and engagement decision signed off by an appropriate authority (e.g. CISO, DPO). Critical vendors should be reassessed at least annually.

What does the vendor risk assessment cover?

A comprehensive pre-engagement assessment should cover at minimum: security posture, privacy compliance, certifications and incident history. Financial and operational resilience assessment is important for critical suppliers.

Do contracts with all vendors who access, process, store or transmit organisational data include binding security and privacy obligations?

Contracts should include at minimum: information security obligations, incident notification timelines (72 hours or less), audit rights, data handling and deletion requirements, sub-processor controls, and exit provisions.

Which of the following clauses are included as standard in your vendor contracts?

All eight clauses are expected in contracts with vendors processing personal or sensitive data. Absence of a DPA for any personal data processor is a direct GDPR compliance gap.

Does your organisation maintain a current register of all sub-processors, notify customers of intended changes, and ensure sub-processors are bound by data protection obligations equivalent to those owed to the controller?

The sub-processor register should be publicly accessible or available to customers on request. Customer notification of sub-processor changes must occur with sufficient notice for the customer to object.

How does your organisation manage changes to the sub-processor list?

Advance notification with a right to object is the standard expected by enterprise customers and is required under GDPR Art.28.2. A published list without proactive notification is a weaker but common approach — the customer should confirm whether this satisfies their contractual requirements.

Does your organisation have a documented process for selecting, configuring, monitoring and exiting cloud service providers, including a documented shared responsibility matrix?

The process should include security baseline configuration standards (e.g. CIS Benchmarks), documented shared responsibility boundaries, and contractual data portability and exit provisions. Misconfiguration of cloud services is a leading cause of security incidents.

Which elements of cloud service provider security management are formally documented in your organisation?

A shared responsibility matrix and documented configuration baseline are the minimum expected artefacts. Exit planning is critical to ensure data can be recovered or migrated if the CSP relationship ends.

Does your organisation maintain an inventory of third-party software components (including open source libraries) embedded in your products, and are these inventories scanned for known vulnerabilities?

A Software Bill of Materials (SBOM) should be generated for every production build. Dependency vulnerability scanning should be integrated into the CI/CD pipeline. Critical and High CVEs must have documented remediation timelines.

How are third-party software components and open source dependencies managed in your development process?

Automated SBOM generation and CI/CD-integrated vulnerability scanning are the baseline expectation for SaaS products. Manual-only dependency management is insufficient given the pace of vulnerability disclosures.

Are vendor security posture, compliance, and contractual performance reviewed at defined intervals (at least annually) with documented findings and escalation of material deficiencies?

Reviews should include: updated security certifications or questionnaire responses, incident history check, SLA performance, and any open findings from the previous review. Material deficiencies should be escalated and tracked to resolution.

What triggers a vendor security review outside of the regular annual cycle?

Event-triggered reviews are critical because vendor risk does not change on a fixed annual schedule. Vendor breaches and significant service changes should always trigger an unscheduled reassessment.

Is all vendor and third-party access to organisational systems, networks and data governed by least-privilege principles, formally authorised, time-limited and monitored?

Vendor accounts must enforce MFA, have scoped permissions (no broad administrative access), and be time-bounded. Privileged vendor sessions should be logged and, where possible, recorded.

Which controls are applied specifically to privileged vendor access (e.g. remote support, admin credentials)?

JIT provisioning, MFA, and session recording are the expected standard for privileged vendor access. Standing, unmonitored vendor accounts with broad access are a high-risk exposure.

Does your organisation follow a documented offboarding procedure when a vendor relationship ends, covering access revocation, data return or destruction, and formal sign-off?

All vendor access credentials (SSO, API keys, service accounts, VPN) must be revoked on or before the termination date. The vendor must provide written confirmation of data deletion or return. Contractual documents including the DPA must be archived.

What does your vendor offboarding checklist include?

All six elements of a complete offboarding should be present. Absence of written vendor confirmation of data deletion is a common gap that creates ongoing liability.

Does your organisation conduct an AI-specific risk assessment for third-party AI components, pre-trained models, AI APIs and AI platform services before integration, evaluating criteria such as bias, training data provenance, data retention and responsible AI alignment?

Standard vendor risk assessments are insufficient for AI components. Assessments must include AI-specific criteria: training data provenance, model transparency, bias risk, data leakage controls, output explainability, and whether customer data is used to train the provider's models.

Which of the following are covered in your organisation's assessment of third-party AI providers?

Prohibition on model training using customer data and defined data retention limits are the minimum requirements for enterprise AI provider agreements. A thorough assessment also addresses bias, explainability and IP risk.

Are all disclosures of personal or sensitive data to third parties authorised, documented in a disclosure register, and governed by a data sharing agreement specifying permitted use and handling obligations?

Every standing third-party disclosure relationship should appear in the data inventory or a dedicated disclosure register. Recipients must be restricted to the minimum data required for the stated purpose, and disclosures must be consistent with what is stated in the privacy notice.

What controls govern the disclosure of personal or sensitive data to third parties?

All six active controls indicate a mature third-party disclosure programme. Absence of a disclosure register makes it impossible to fulfil data subject requests or demonstrate accountability to a supervisory authority.