Security Checkpoints

A security checkpoint is a control point during a project where requirements must be met before proceeding.

Depending on the security level a delivery aims to achieve, it may be necessary to define mechanisms for assessing security at fixed points in the development cycle, known as security checkpoints.

These can be defined between logical phases in the project, for example, between the design and development phases, or when transitioning from development to the first release in production. Other and additional checkpoints can also be defined, entirely depending on the requirements the delivery team must adhere to.

In a study by IBM it was determined that defects in applications developed for the U.S. military cost significantly less to fix early in the process compared to later.

By implementing security checkpoints, it becomes easier to catch weaknesses early and to ensure compliance with security and quality requirements. A typical practice using checkpoints could include

creating a design of the project before the development cycle starts
ensuring that implementation follows the design
verifying that design and implementation actually match before going into production

AI-specific security checkpoints

For solutions that use AI, dedicated checkpoints should be established before production deployment. The goal is to ensure that data, model behavior, and operational readiness are reviewed and documented before the solution is exposed in production.

A practical minimum is to introduce the following gates:

1. Data review gate

Before model training, fine-tuning, or major changes to the data basis, the team should document:

which data sources are used, ownership, and permitted usage purpose
a basic data quality assessment (representativeness, missing values, noise, duplicates)
identified privacy and security risks in the data basis
decisions on any data limitations, filtering, or rejected datasets

2. Evaluation and V&V gate

Before production, the model should be verified and validated against defined acceptance criteria:

a documented evaluation setup with relevant test sets and scenarios
assessment of security and misuse scenarios (for example prompt injection and unwanted tool usage)
clear boundaries for when the model must not be used without human oversight
a go/no-go decision with rationale

3. Logging and monitoring gate

Before production, the operations team should verify that required observability is in place:

which events must be logged (model calls, access changes, failures, anomalies)
how logs are protected against tampering and unauthorized access
which alerts and thresholds should trigger follow-up
who is responsible for ongoing monitoring and incident handling

For more on log operations and production follow-up, see Logging and Monitoring.

More Information

Last modified May 13, 2026: Merge pull request #258 from bouvet/iso-42001-implementation (a1f6421)