> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atlasent.io/llms.txt
> Use this file to discover all available pages before exploring further.

# GxP change control

> Execution-time authorization patterns for regulated system changes, their quality-system evidence, and what must be proven before a customer enforcement claim.

GxP change control is about more than recording an approved ticket. For any change that can alter a validated process or computerized system, the executing system must know whether **this exact change, by this actor, against this system and version, is currently authorized**.

AtlaSent's authorization architecture can provide this decision boundary. **A policy template or a simulated evaluation is not evidence that a particular MES, LIMS, ERP, or production system is protected.** The actual execution system must be integrated and acceptance-tested.

<Warning>
  **Integration and validation boundary.** This page describes a proposed GxP control pattern, not a qualified or GxP-validated deployment. A customer-specific regulated use requires appropriate QA/validation oversight, system risk assessment, change control, qualification, and proof that unauthorized execution cannot bypass the accepted gate.
</Warning>

<CardGroup cols={2}>
  <Card title="Explore GMP control scenarios" icon="flask-conical" href="/gmp">
    See the synthetic batch-release, data-integrity, and process-control scenarios and their limits.
  </Card>

  <Card title="Request a GMP demonstration" icon="calendar" href="https://cal.com/atlasent/discovery?utm_source=docs&utm_medium=gxp-change-control">
    Bring one controlled action and discuss the exact execution boundary.
  </Card>
</CardGroup>

## Requirement-to-control design

The references below inform a qualified organization's intended-use analysis; the mapping is **not a certification or compliance determination**.

| Reference | Control concern to evaluate | Candidate AtlaSent authorization input |
| - | - | - |
| ICH Q10 change management | Approved assessment and organizational approval of relevant changes | Change identifier, risk classification, approved quality decision, actor authority |
| EU GMP Annex 15 | Assessment and evidence of the effect of changes on validated status | Validation impact, affected equipment/process, documented test and release criteria |
| EU GMP Annex 11 | Formal control of changes to computerized systems | Target system, exact proposed change, approved change record, execution boundary |
| 21 CFR 211.100 | Written production/process procedures and controlled execution | Authorized change type, controlled procedure reference, qualified operator |
| 21 CFR Part 11, where applicable | Reliable electronic records and electronic signatures | Appropriate identity, signature linkage, record integrity, attributable evidence |

## Illustration: a proposed system change

This is an **illustrative context shape**, not a copy-and-paste request guaranteed to match the deployed API or a released policy pack.

```json theme={null}
{
  "change_ticket_id": "CHG-EXAMPLE-102",
  "system_name": "LIMS-example",
  "change_type": "software_update",
  "target_environment": "regulated-production",
  "risk_level": "major",
  "validation_impact": "revalidation_required",
  "quality_approval_status": "approved",
  "rollback_plan_verified": true
}
```

Do not take an approval field supplied by the requesting actor on trust. The enforcing design must resolve or independently verify required facts from the authoritative quality/change system.

## Acceptance criteria for an enforcing implementation

1. **Locate the native action.** Identify where the target system commits the change; evaluating a form submission alone may leave alternate paths open.
2. **Bind the request.** Include the exact target, version or content digest, authorized actor, and appropriate change evidence.
3. **Evaluate fresh authority.** Resolve quality approvals, identity, responsibilities, training and relevant version/currentness from authoritative sources.
4. **Verify the permit before execution.** A deny, hold, timeout, mismatch, expired or replayed permit must leave the protected effect unreachable on the accepted path.
5. **Prove the outcome separately.** Record the determination and execution-point check; establish the system's applied state by native readback rather than inferring success from an authorization decision.
6. **Test bypass and failure conditions.** Demonstrate behavior for alternate callers, retries, change mutations, stale approvers, unavailable facts, and service outages.
7. **Complete customer validation.** The customer decides whether the controls and evidence are adequate for their intended regulated use, with qualified QA/validation approval.

An integration that cannot intercept the actual side effect is **observe-only**. It can support later review and reconciliation, but it cannot honestly claim to prevent an unauthorized change.

## Explore and discuss

Start with [GMP control scenarios](/gmp), then [21 CFR Part 11](/compliance/21-cfr-part-11), [EU GMP Annex 11](/compliance/eu-annex-11), and [published compliance status](/trust/compliance-status). To scope a specific execution boundary, [request a GMP control demonstration](https://cal.com/atlasent/discovery?utm_source=docs\&utm_medium=gxp-change-control\&utm_campaign=demo).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.