Connect981 – Content Dev

RSC Topic: Audit Readiness & Evidence Management

Ongoing audit-proof documentation, approvals, and revision histories.

  • FAIR (First Article Inspection Report)

    A First Article Inspection Report (FAIR) is the documented record of a formal First Article Inspection (FAI). It captures evidence that an initial production part or assembly has been manufactured and measured against all applicable design, drawing, and specification requirements, and that the results meet those requirements within defined tolerances.

    What a FAIR typically includes

    In regulated and aerospace-focused manufacturing, a FAIR commonly contains:

    • Identification of the part, revision level, drawing number, and related specifications
    • Manufacturer and supplier details, including lot or batch information
    • Ballooned (numbered) drawing characteristic list linking each requirement to an inspection result
    • Measured values for dimensional, material, and functional characteristics
    • Notes on special processes, treatments, or key characteristics when applicable
    • References to supporting records (e.g., material certs, process certifications, test reports)
    • Signatures or approvals from responsible quality and/or engineering representatives

    Where FAIR is used in operations

    Operationally, a FAIR is used to document that the manufacturing process for a new or changed part is capable of producing results that conform to requirements. It is often required:

    • For new part numbers or first-time builds
    • After significant design changes or drawing revisions
    • After major process, tooling, or manufacturing location changes
    • When required by customer, contractual, or industry standards such as AS9102

    In many plants, FAIRs are generated or managed within quality systems, MES, or dedicated FAI software and may be exchanged electronically with customers or prime contractors.

    Relationship to AS9102 and aerospace

    In aerospace, FAIR commonly refers to the standardized reporting format aligned with AS9102 First Article Inspection requirements. AS9102 describes typical forms and data elements for documenting FAIs on aviation, space, and defense products, but organizations may implement FAIRs in paper or digital formats as long as contractual and standard requirements are addressed.

    What FAIR is not

    • It is not routine in-process or final inspection for every lot, although it may reference those controls.
    • It is not a statistical process capability study, even though it can trigger further analysis.
    • It is not a general nonconformance report, although nonconformances found during FAI may be documented separately and referenced by the FAIR.

    Common confusion

    • FAI vs. FAIR: FAI refers to the inspection activity; FAIR is the documented report of that activity.
    • PPAP vs. FAIR: In automotive, Production Part Approval Process (PPAP) covers a broader submission package. A FAIR in aerospace is more narrowly focused on first article inspection results, though it can serve a similar verification role.

  • evidence package

    An evidence package is a structured collection of records, documents, and system-generated data assembled to support a review, inspection, audit, release decision, or customer deliverable. In manufacturing and regulated operations, it commonly refers to the documented proof that required steps were completed, approvals were recorded, and specifications or procedural requirements were addressed.

    The package may include forms, inspection results, training or qualification records, approvals, material certifications, device or equipment records, traceability data, change history, and related attachments. The exact contents vary by process and industry, but the core idea is consistent: it groups relevant evidence so another party can verify what happened and on what basis.

    What it includes and what it does not

    An evidence package includes supporting records that are relevant to a defined scope, such as a batch, work order, first article, deviation review, supplier event, or validation activity. It is usually organized around a specific question like whether work was completed correctly, whether required checks were performed, or whether documentation is complete.

    It is not the same as the underlying process itself, and it is not necessarily a single document. It is also not automatically a formal certification file or legal record set, although it may contain records used for those purposes.

    How it appears in operations and systems

    In practice, an evidence package may be assembled manually from paper and electronic records, or generated from connected systems such as MES, ERP, QMS, LIMS, PLM, or document management platforms. In digital environments, the package often pulls together approved versions of documents, timestamps, user actions, electronic signatures where applicable, exception records, and traceability links.

    Examples in manufacturing include:

    • a batch or device history record assembled for product release
    • a first article inspection package containing drawing characteristics, measurement results, and approvals
    • an audit support package with training records, procedures, and change history
    • a nonconformance review package with defect details, disposition, and related corrective action records

    Common confusion

    Evidence package is often confused with document package, submission package, or audit trail. A document package may simply be a set of files, while an evidence package is assembled specifically to support verification. An audit trail is usually the chronological log of actions within a system, which may be one component of an evidence package rather than the whole package.

    It can also be confused with a data package or turnover package. Those terms may overlap, but they can include broader technical or handoff materials that are not strictly evidentiary.

    Why the term matters

    The term is commonly used where organizations need to demonstrate traceability, completeness, and controlled execution across quality, production, maintenance, validation, or supplier-related workflows. Its value is mainly organizational and evidentiary: it brings together the records needed for review without changing the underlying requirements those records are meant to support.

  • certification scope

    Certification scope commonly refers to the formally defined boundaries of what an external certification or registration covers for an organization. It describes which activities, sites, processes, products, and services are included under a specific standard or scheme (such as ISO 9001, AS9100, or cybersecurity frameworks).

    The certification scope is typically documented in the certificate itself and in associated internal records. It is used by customers, regulators, and internal teams to understand where a particular certification applies and where it does not.

    What certification scope usually includes

    In industrial and regulated manufacturing environments, certification scope commonly defines:

    • Organizational boundaries: specific legal entities, sites, plants, or business units included in the certification.
    • Activities and processes: types of operations covered, such as design, manufacturing, assembly, test, inspection, repair, or distribution.
    • Products and services: product families, component types, systems, or service offerings that fall under the certified system.
    • Applicable standards: which standard(s) the scope relates to, for example ISO 9001, AS9100, ISO 27001 or CMMC.
    • Limitations and exclusions: processes or functions not covered, such as design-excluded scopes or non-certified sites.

    Operationally, the certification scope should be reflected in quality management systems, MES/ERP configurations, document control, and customer-facing information so it is clear which work is performed under which certified environment.

    Use in multi-site and integrated operations

    In multi-site manufacturers, different plants or business units may have different certification scopes. For example, one site may be certified for AS9100 including design, while another is certified only for production of specific part families. In these cases, organizations typically:

    • Map products, programs, and customers to the sites that are within the relevant certification scope.
    • Configure routing, work orders, and approved supplier lists so certified and non-certified flows do not get confused.
    • Maintain evidence showing that activities claimed as certified actually occur within the defined scope.

    Common confusion

    • Certification scope vs. process scope: Process scope describes the boundaries of a specific process or procedure (for example, what a work instruction covers). Certification scope is broader and tied to a formal external certification.
    • Certification scope vs. organization-wide coverage: A company may be certified only for part of its operations. It is incorrect to assume that a single certification automatically covers every site, product, or service unless the documented scope states this.
    • Certification scope vs. regulatory applicability: Certification scope is defined for a standard or scheme and does not, by itself, determine whether a regulation applies. Regulatory scope is set by laws or authorities, even if certification is used as supporting evidence.

    Relation to audits and evidence

    During external audits, auditors typically verify that the management system and collected evidence match the declared certification scope. Internally, operations, quality, and IT/OT teams often use the scope to decide:

    • Which processes must follow certified procedures and controls.
    • Which records must be retained as evidence for the certified activities.
    • How changes to products, sites, or IT/MES systems affect what is inside or outside the scope.

    Clear and maintained certification scope helps prevent incorrect claims about coverage and supports accurate communication to customers and regulators.

  • contract review

    Contract review is the formal evaluation of a proposed contract or order before it is accepted, to confirm that all technical, quality, delivery, regulatory, and commercial requirements are understood, feasible, and aligned with the organization’s capabilities and systems.

    Key characteristics

    In industrial and regulated manufacturing environments, contract review commonly includes:

    • Checking that drawings, specifications, standards, and revisions referenced in the contract are available and controlled
    • Verifying that special processes, certifications, or regulatory requirements (for example aerospace, defense, medical) are identified and can be met
    • Confirming capacity, lead times, and material availability against requested quantities and delivery dates
    • Reviewing quality requirements such as inspection levels, FAI/AS9102, traceability, documentation, and record retention
    • Ensuring commercial terms (pricing, penalties, warranty, change control) are understood by relevant internal functions
    • Aligning customer requirements with internal routings, BOMs, work instructions, and ERP/MES data
    • Documenting clarifications, deviations, or concessions that must be agreed with the customer before acceptance

    Contract review can apply to customer contracts, purchase orders (POs), long-term agreements (LTAs), and significant changes to existing contracts.

    How it appears in operations and systems

    Operationally, contract review is often implemented as a cross-functional process involving sales, program management, engineering, quality, and operations. Evidence of contract review may be found in:

    • Signed-off review checklists or forms attached to quotes or sales orders
    • ERP or CRM workflows that require approval before an order is released to production
    • Engineering reviews to translate contract requirements into controlled drawings, routings, and work instructions
    • Quality system records showing how special quality and regulatory requirements were identified and communicated to the shop floor and suppliers

    Use in quality management and audits

    Quality management standards such as ISO 9001 and AS9100 commonly refer to contract review (often under "review of requirements for products and services" or "contractual requirements"). Auditors frequently look for:

    • Defined procedures describing how contracts and orders are reviewed before acceptance
    • Objective evidence that reviews were performed for sampled orders, including who reviewed and when
    • Records of resolved discrepancies between customer requirements and internal capability
    • Linkage between contract requirements and downstream controls, such as inspection plans, FAI, or special-process qualifications

    Common confusion

    • Contract review vs. legal review: Contract review in a manufacturing QMS focuses on operational and technical feasibility, not only legal risk. Legal review may be a part of contract review for complex agreements but is not the whole process.
    • Contract review vs. order entry: Order entry is the administrative act of loading an order into ERP or another system. Contract review is the prior or parallel evaluation step that confirms the order should be accepted and under what conditions.

    Relation to the derived context

    In the context of AS9100 Rev D, contract review is a key source of audit evidence showing that customer and regulatory requirements are identified, understood, and translated into controlled processes, documents, and records before work is started.

  • certification body (CB)

    A certification body (CB) is an independent organization that assesses and certifies that a company, process, or management system conforms to a specified standard or scheme. In industrial and regulated manufacturing environments, CBs are central to third-party certification to standards such as AS9100, ISO 9001, or other sector-specific quality and compliance frameworks.

    What a certification body does

    A CB typically performs the following activities:

    • Conducts initial audits to determine whether an organization's management system meets the chosen standard.
    • Issues certificates that formally recognize conformity to that standard, with defined scope and validity period.
    • Performs surveillance and recertification audits at planned intervals to confirm that the system is maintained.
    • Maintains audit records and certification status information in internal systems and sometimes in sector databases (for example, OASIS for AS9100).
    • Suspends or withdraws certificates if major nonconformities are not addressed within required time frames.

    In aerospace and other regulated sectors, CBs must themselves be accredited by a recognized accreditation body. This accreditation confirms that the CB operates to agreed rules for auditor competence, impartiality, audit methods, and oversight.

    Role in manufacturing and supplier management

    In manufacturing, CB-issued certificates are commonly used to:

    • Demonstrate that an organization's quality management system meets a standard such as AS9100 or ISO 9001.
    • Support customer and regulatory requirements for certified suppliers or production sites.
    • Provide traceable evidence of audits, findings, and certification status during customer or regulatory reviews.

    Buying organizations often verify a supplier's certification status, scope, and the identity of the CB through certificates and sector databases. This verification is usually treated as one input to supplier qualification and ongoing risk management, not a replacement for internal oversight.

    What a certification body is not

    • It is not the same as an internal audit team or second-party (customer) auditor. CBs are third-party, independent organizations.
    • It is not a regulatory authority and generally does not grant legal permissions to operate.
    • It does not manage a company's day-to-day quality system or ensure continuous compliance on its behalf.

    Common confusion

    • Certification body vs. accreditation body: An accreditation body evaluates and approves CBs themselves. A certification body evaluates and certifies manufacturing organizations.
    • Certification body vs. standard owner: Standards (for example, AS9100-series) are developed and maintained by standards organizations or industry groups. CBs apply those standards during audits but do not define their content.

    Link to OASIS and aerospace context

    In the aerospace sector, CBs that certify organizations to the AS9100-series standards are recognized and monitored through industry schemes. They are responsible for entering and maintaining accurate certification and audit data in directories such as the IAQG OASIS database. Manufacturers and customers use this information to verify supplier certification status, scope, and audit history as part of supplier control processes.

  • as-built records

    As-built records are documented evidence of how a product, subsystem, or facility was actually manufactured, assembled, configured, and tested, including any approved deviations from the original design or plan. They capture the real, final state of the build, not just the intended design.

    What as-built records include

    In industrial and regulated manufacturing environments, as-built records commonly include:

    • Final bill of materials (BOM) as used, including alternates and substitutions
    • Serialized component and material traceability, including lot, heat, or batch numbers
    • Final routing, process steps, and work centers actually used
    • Process parameters and key production data where captured (for example, torque values, oven profiles, test results)
    • Approved deviations, concessions, waivers, and rework dispositions affecting the build
    • Inspection, test, and verification records tied to the specific unit or batch
    • Configuration and software/firmware versions installed at release

    These records may be compiled from multiple systems such as MES, ERP, PLM, QMS, and test systems, and are often retained as the authoritative reference for what was actually delivered.

    Where as-built records are used

    As-built records are commonly used for:

    • Regulatory and customer traceability in aerospace, defense, medical devices, and other regulated industries
    • Supporting audits, investigations, and field issue analysis by showing exact build and configuration history
    • Enabling maintenance, repair, and overhaul (MRO) by providing the starting configuration of an asset
    • Supporting engineering changes, retrofits, and upgrades by comparing as-designed, as-planned, and as-built states

    Relationship to other record types

    As-built records are related to but distinct from:

    • As-designed data: The engineering intent, typically managed in CAD/PLM (models, drawings, specifications).
    • As-planned data: How production intends to build, usually in ERP/MES (routings, work instructions, planned BOM).
    • Device or batch history records: In some industries (for example, medical), the formal Device History Record (DHR) or batch record is the regulated package of evidence. As-built records are often a core component of that package.

    Common confusion

    The term “as-built records” is sometimes used interchangeably with:

    • As-built drawings, which focus specifically on updated design documents showing the final physical configuration. As-built records are broader and include process and traceability data, not only drawings.
    • Configuration records, which emphasize versions and options selected. As-built records usually include configuration but also cover how the configuration was achieved in production.

    Ties to digital operations

    In digital manufacturing and MES environments, as-built records are often generated automatically as production executes. Data from work orders, digital travelers, test systems, and quality workflows is aggregated to form a digital as-built or digital birth record for each serialized unit or batch. This supports audits, change control, and plant-wide traceability without disrupting ongoing production.

  • audit and accountability

    Audit and accountability commonly refers to the set of policies, processes, and technical controls that ensure actions in an information or operational system can be recorded, traced, reviewed, and attributed to responsible entities. In industrial and manufacturing environments, this applies to both IT and OT systems that handle production data, quality records, recipes, maintenance activities, and configuration changes.

    Core meaning

    In security and compliance frameworks, including NIST SP 800-53, “audit and accountability” typically covers:

    • Audit records (logs): System, application, and device logs that capture key events such as logins, parameter changes, batch release decisions, recipe downloads, or override of interlocks.
    • Audit mechanisms: The tools and configurations that generate, protect, time-stamp, and retain those records in a consistent, tamper-evident way.
    • Traceability of actions: The ability to associate actions with specific users, roles, systems, equipment, or service accounts.
    • Accountability structures: Defined responsibilities and authorities for who can perform, approve, review, or investigate activities recorded in the system.
    • Review and reporting: Procedures for regularly reviewing logs, investigating anomalies, and documenting follow-up actions.

    In manufacturing operations, audit and accountability typically includes:

    • Recording who created, modified, or approved work instructions, recipes, or batch records.
    • Logging configuration changes on PLCs, DCS, MES, LIMS, or ERP integrations.
    • Tracking user access, privilege changes, and authentication events on critical systems.
    • Maintaining audit trails for quality decisions such as holds, deviations, nonconformance dispositions, and CAPA actions.
    • Ensuring time-synchronized records so events can be reconstructed across systems during an investigation or audit.

    Scope and boundaries

    Audit and accountability focuses on evidence and traceability, not on process design itself. It typically includes:

    • Log configuration and retention requirements.
    • User identification and activity attribution.
    • Mechanisms to prevent, detect, or signal log tampering.
    • Defined reviews of records (for example, periodic security or quality log review).

    It usually does not include:

    • Real-time process control logic (that is covered by control, safety, or automation design).
    • Business performance metrics that do not relate to who did what and when.
    • Certification or regulatory approval; it only provides evidence that may be evaluated in audits or inspections.

    Operational use in regulated manufacturing

    In regulated industrial settings, audit and accountability controls show up in daily operations through:

    • Electronic records: Audit trails linked to batch records, device history records, or electronic logbooks that capture each critical change with user, date, time, and reason.
    • System administration: Access control policies, user provisioning, and periodic access reviews that ensure only authorized personnel can perform certain actions.
    • Incident and deviation investigations: Use of logs and audit trails to reconstruct events and understand who initiated or approved changes.
    • Internal and external audits: Availability of clear records that demonstrate how systems are used, who is accountable, and how exceptions are handled.

    Relation to NIST security controls

    Within NIST SP 800-53 and related publications, “Audit and Accountability” is a control family that defines requirements for generating, protecting, reviewing, and using audit records. Organizations implementing these controls in industrial environments typically:

    • Select specific audit and accountability controls applicable to their systems.
    • Tailor them to OT and manufacturing systems, such as HMIs, historians, MES, or equipment controllers.
    • Integrate audit logs with centralized log management or security monitoring tools when feasible.

    These controls provide a structured catalog of expectations for logging and traceability, but they do not by themselves guarantee compliance, safety, or a specific audit outcome. Effectiveness depends on how they are implemented, integrated, and reviewed in the actual environment.

    Common confusion

    • Audit and accountability vs. quality audit: A quality audit is an event or activity (for example, an inspection or assessment). Audit and accountability refers more broadly to the ongoing mechanisms and responsibilities that generate and manage records used in such audits.
    • Audit and accountability vs. logging only: Simple logging captures events, but audit and accountability also requires being able to attribute events to specific entities, protect the integrity of records, and define who is responsible for reviewing and acting on them.
    • Audit and accountability vs. access control: Access control limits who can perform actions. Audit and accountability focuses on recording and tracing actions that occur, whether allowed or not.

  • How can we make ISO 22400 KPI calculations auditable?

    Making ISO 22400 KPI calculations auditable is less about the standard itself and more about how you define, implement, and govern the KPI logic in your systems. In regulated, brownfield plants, auditable KPIs require unambiguous definitions, reliable data capture, controlled calculation logic, and reproducible results backed by evidence.

    1. Start with precise, written KPI definitions

    ISO 22400 describes concepts and reference calculations, but each plant still makes choices. To be auditable, you should maintain a KPI definition sheet for each KPI that includes at least:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    • Name and identifier (e.g., ISO22400_OEE_V1, ISO22400_Availability_V2).
    • Scope: line, machine group, shift, product family, plant; plus time horizon (shift, day, week).
    • Exact formula, including units and references to the specific ISO 22400 clause or figure where applicable.
    • Time base definitions: what counts as planned time, operating time, planned/unplanned downtime, and which status codes map to each bucket.
    • Included and excluded events: e.g., warmup, maintenance, testing, changeovers, engineering trials, rework.
    • Data fields used: system, table, tag, or signal names (from MES, historian, PLC, ERP, QMS, etc.).
    • Aggregation rules: how you roll up across shifts, machines, or orders (e.g., weighted by planned time or output quantity).
    • Known limitations and assumptions: for example, how you handle missing machine states, partial cycles, or backfilled production counts.

    Auditors will challenge anything that is ambiguous or inconsistently applied across lines or plants. Written definitions are the baseline for repeatability.

    2. Make data lineage from KPI to raw signals traceable

    To be auditable, anyone should be able to start from a reported KPI value and trace back to:

    • The underlying time series of machine states and production counts.
    • The work orders, part numbers, and shift calendars involved.
    • The exact calculation logic and version that produced the result.

    Practical steps:

    • Retain time-stamped raw data from MES, SCADA/PLC, historian, and ERP at a resolution that supports reconstruction of events (for many KPIs, 1-second to 1-minute resolution is typical).
    • Maintain a data dictionary that maps source tags and fields (e.g., PLC bits, MES state codes, ERP order status) to KPI categories such as operating time, minor stop, changeover, scrap, or rework.
    • Record data transformations (e.g., state code reclassification, time bucket merging, filtering of obvious noise or outliers) with versioned logic.
    • Keep referential links between production events, work orders, batches, and KPIs (e.g., a KPI instance references specific order IDs and date ranges).

    If your KPI platform cannot show how a value was derived from raw data, auditors will treat it as a dashboard number rather than as reliable evidence.

    3. Put calculation logic under change control

    Many plants implement ISO 22400 KPIs in multiple places: historian scripts, MES reports, BI tools, or custom SQL. This is a common source of non-auditable discrepancies.

    To keep calculations auditable:

    • Centralize KPI logic as much as possible in a single, validated layer (e.g., MES or an analytics engine) and treat that as the system of record.
    • Apply formal change control to KPI definitions and logic: documented change requests, impact assessment, testing, approvals, and effective dates.
    • Version all calculation code and configurations (SQL, ETL flows, scripts, BI measures) in a repository where you can reconstruct the exact logic used on any historical date.
    • Document deviations from ISO 22400: if you implement a plant-specific variant of OEE or availability, label and document it as such rather than calling it “ISO 22400” without qualification.

    In regulated environments, ad hoc dashboard logic without version control is a major audit risk, even if the formulas are mathematically correct.

    4. Validate the full calculation pipeline

    In aerospace, pharma, and other regulated sectors, KPI numbers are often used to support capacity decisions, improvement programs, and sometimes compliance evidence. That makes the calculation pipeline itself subject to validation expectations.

    Consider a basic validation approach:

    • Define intended use: for example, “shift-level ISO 22400 availability and OEE for internal performance management, not used directly for product release decisions.”
    • Perform installation and operational checks: confirm data flows from each source (MES, historian, ERP) are complete, time-synchronized, and secure.
    • Develop test cases: use controlled historical periods where states and counts are known (e.g., a planned training day with a known stop pattern) and verify that your pipeline reproduces the expected KPI values.
    • Document limitations: for example, “Cycle counts on Line 3 prior to date X are underreported during minor stops due to PLC configuration; KPI values before that date are not fully comparable.”

    If your organization is subject to formal CSV or software validation expectations, your KPI tooling and data integration stack may fall in scope. Work with quality and IT to set appropriate validation depth.

    5. Ensure consistent handling of time, shifts, and calendars

    ISO 22400 KPIs such as availability, utilization, and OEE depend heavily on how you define planned time and schedule exceptions. These details are common audit failure points.

    • Use controlled calendars for shifts, holidays, and site-specific events, ideally managed in a master system (MES, HR, or scheduling tool) and propagated downstream.
    • Define standard rules for how you treat early starts, overtime, partial shifts, and overlap between shifts.
    • Classify schedule exceptions explicitly: e.g., planned maintenance, trials, and engineering work that should be removed from planned production time.
    • Synchronize time zones and clocks across OT and IT systems so that event sequences remain reconstructable.

    Auditable KPIs require that two analysts using the same rules and data can independently reproduce the same results for a given period.

    6. Design reports for drill-down and reproducibility

    Auditability also depends on practical usability. Reports and dashboards should support tracing a number back to its components.

    • Make drill-down supported: from monthly OEE to daily, shift-level, machine-level, and event-level views.
    • Show KPI components: for example, for OEE, separately display availability, performance, and quality, with their numerators and denominators.
    • Display applied filters and versions: time range, scope, excluded events, and KPI definition version.
    • Allow export of underlying event data for sampled periods to support manual recalculation and evidence reviews.

    If an auditor cannot inspect how a KPI changed when they adjust time filters or drill down into a particular machine or order, they will question its reliability.

    7. Manage coexistence with legacy MES, historians, and BI tools

    Most plants already calculate some form of OEE or ISO 22400-like KPIs in multiple systems. Full replacement is rarely realistic due to validation burden and downtime risk. Instead:

    • Pick one system as the KPI system of record for ISO 22400-aligned metrics, then document that all official numbers come from there.
    • Map and reconcile existing metrics in legacy tools to the new definitions; document differences (e.g., “Old_OEE includes planned maintenance as downtime; ISO22400_OEE excludes it.”).
    • Phase out non-comparable KPIs or clearly label them as legacy indicators to avoid mixing them with ISO 22400 KPIs in formal reports.
    • Implement interface tests to ensure data extracted from MES/ERP/historian into the KPI engine matches the source (record counts, sums, sample spot-checks).

    Auditability suffers when multiple conflicting KPI values exist for the same period without a clear explanation. Reconciliation and labeling are essential during transition.

    8. Capture governance, ownership, and training

    Even with robust technical controls, ISO 22400 KPI calculations will not be auditable unless people understand and follow the rules.

    • Assign ownership for each KPI (typically operations or industrial engineering) with clear responsibilities for definition, review, and continuous improvement.
    • Set a review cadence where KPI definitions, data quality, and observed anomalies are periodically checked and updated under change control.
    • Train key users (engineers, supervisors, analysts) on the definitions, typical pitfalls (e.g., double-counting, misclassified downtime), and how to respond to audit questions.
    • Maintain an evidence pack for each key KPI: definition documents, sample calculations, validation records, and recent change logs.

    9. What auditors will typically look for

    While specific expectations vary by regulator and customer, auditors reviewing ISO 22400-style KPIs used in decision-making commonly test:

    • Can you explain the formula and link it to ISO 22400 where applicable?
    • Can you trace a reported value back to raw data, with consistent time stamps and event records?
    • Is the calculation logic controlled and versioned, with documented changes and approvals?
    • Are there documented data quality controls and known limitations?
    • Can two people independently recalculate and match a sample KPI period using the same data and rules?

    If you can provide clear answers and evidence for these points, your ISO 22400 KPI calculations will generally be considered auditable, even in complex, mixed-vendor environments.