Connect981 – Content Dev

RSC Cluster: Audit and Compliance Readiness (AS9100, LPAs and Process Audits)

The Audit and Compliance Readiness Cluster focuses on turning audit preparation into continuous evidence rather than episodic panic. It explains what auditors actually expect to see across training, revision control, traceability, and execution records. The content covers internal audits, layered process audits, and AS9100 expectations using real operational examples. This cluster helps organizations stay audit-ready by design, not by scramble.

  • regulated manufacturing

    Regulated manufacturing commonly refers to manufacturing activities that are subject to formal laws, regulations, and standards imposed by governmental or recognized regulatory bodies. In these environments, how products are designed, produced, tested, documented, and released is constrained by defined rules rather than left solely to internal company policy.

    Core characteristics

    Regulated manufacturing typically includes:

    • External oversight: Operations are subject to inspection, review, or registration by regulators or notified bodies.
    • Defined requirements: There are explicit rules for product quality, safety, labeling, traceability, and recordkeeping.
    • Documented processes: Procedures, work instructions, and controls must be documented, maintained, and followed.
    • Evidence of compliance: Organizations must keep records that show how requirements were met, often for long retention periods.
    • Change control: Changes to materials, processes, equipment, software, or suppliers often require formal impact assessment and approval.

    Examples include pharmaceutical and biotech manufacturing, medical devices, aerospace and defense, certain food and beverage operations, and other sectors where health, safety, or public interest is directly affected.

    Operational meaning in manufacturing systems

    In regulated manufacturing, operational systems such as MES, ERP, quality management systems, and plant-floor control systems are expected to support compliance-related needs. Typical operational implications include:

    • Traceability and genealogy: Ability to track materials, components, equipment, and process parameters through each batch or unit.
    • Electronic records and signatures: Structured capture of who did what, when, and under which procedure or recipe.
    • Validated systems and processes: Demonstrated fitness of critical systems and processes for their intended use, with controlled configuration and change history.
    • Nonconformance and CAPA handling: Defined workflows for documenting deviations, investigations, and corrective or preventive actions.
    • Document control: Governance of versions of SOPs, work instructions, specifications, and recipes used on the shop floor.

    What regulated manufacturing is not

    • It is not limited to a single industry; many sectors have regulated segments.
    • It is not the same as following internal best practices; it specifically involves compliance with external rules.
    • It does not imply any claim of certification or approval; it simply describes that operations fall under regulatory scope.

    Common confusion

    Regulated vs. certified: A site may operate in a regulated industry without holding a particular certification, and a site can hold a certification while still needing to meet other regulatory obligations. The term “regulated manufacturing” refers broadly to being under regulatory requirements, not to any specific certificate or audit outcome.

    Regulated vs. high-risk: Some high-risk operations are tightly regulated, but risk level and legal regulation are not identical. Regulated manufacturing is defined by the presence of formal external requirements, not only by perceived risk.

    Relation to operations management

    In operations management, common lenses such as the “5 P’s” (People, Plant, Processes, Parts, and Planning) still apply in regulated manufacturing, but they must be implemented within the constraints of applicable regulations, standards, and validated procedures. For example, process design, staffing, equipment setup, and material flows are planned with explicit attention to auditability, traceability, and documented control.

  • Stage 2 Audit

    A Stage 2 Audit is the second, formal phase of a management system certification audit. It is typically performed by an accredited third-party certification body to determine whether an organization’s management system has been fully implemented and is effective in meeting the requirements of a chosen standard, such as ISO 9001, ISO 13485, or ISO 27001.

    What a Stage 2 Audit Includes

    The Stage 2 Audit builds on the Stage 1 Audit (readiness and documentation review) and focuses on how the system works in practice. In industrial and manufacturing environments, it commonly includes:

    • Review of implemented processes on the shop floor, in quality, maintenance, and supporting functions
    • Verification that procedures, work instructions, and records are used as defined in the management system
    • Interviews with operators, engineers, supervisors, and management to confirm understanding of roles and processes
    • Sampling of records and data in MES, QMS, ERP, LIMS, and other OT/IT systems for traceability, change control, and deviation/CAPA handling
    • Evaluation of compliance with regulatory or customer requirements that are referenced in the management system
    • Assessment of monitoring, measurement, internal audits, and management review activities

    The outcome of a Stage 2 Audit typically includes documented findings such as conformities, nonconformities, and opportunities for improvement. These findings are used by the certification body to decide whether to recommend initial certification of the management system.

    Where It Fits in the Certification Cycle

    A Stage 2 Audit is part of the initial certification process and normally follows this sequence:

    1. Stage 1 Audit: Review of documented information, scope, and readiness.
    2. Stage 2 Audit: Evaluation of implementation and effectiveness across relevant sites and processes.
    3. Surveillance Audits: Periodic follow-up audits to confirm ongoing conformity.
    4. Recertification Audit: Broader review before the certification cycle renews.

    Operational Meaning in Manufacturing

    In manufacturing, a Stage 2 Audit commonly involves:

    • Walking production lines to see how standard work, digital work instructions, and change controls are applied
    • Checking batch records, device history records, or lot genealogy for completeness and traceability
    • Reviewing how nonconforming product, deviations, and CAPAs are identified, investigated, and documented
    • Confirming calibration and maintenance controls for production and test equipment
    • Validating that data in MES, QMS, and ERP systems is controlled, retrievable, and linked to the management system requirements

    Common Confusion

    • Stage 2 Audit vs. Stage 1 Audit: Stage 1 focuses on readiness and high-level design of the management system. Stage 2 focuses on actual operation and evidence of effectiveness.
    • Stage 2 Audit vs. internal audit: An internal audit is performed by or on behalf of the organization itself to assess its own system. A Stage 2 Audit is performed by an external certification body as part of initial certification.
    • Stage 2 Audit vs. regulatory inspection: A Stage 2 Audit assesses conformity to a voluntary or contractual standard. A regulatory inspection is performed by a regulator to assess compliance with laws or regulations.

    Use in Regulated and High-Risk Industries

    In regulated environments, such as pharmaceuticals, medical devices, aerospace, or food and beverage, Stage 2 Audits often place particular emphasis on:

    • Document control and version management of procedures, specifications, and electronic records
    • Data integrity and access control for OT and IT systems used as quality or production records
    • Risk management processes that connect design, process control, and production monitoring
    • Evidence that the organization identifies, investigates, and corrects systemic issues

    While Stage 2 Audits are frequently associated with ISO-based certifications, the general concept applies to other formal certification schemes that use a staged audit model.

  • audit scope

    Audit scope is the formally defined boundary of an audit, describing what will be evaluated and what is excluded. In industrial and regulated manufacturing environments, it typically specifies which sites, processes, product lines, departments, time periods, standards, and information systems are covered by a specific audit activity.

    What audit scope usually includes

    In practice, an audit scope description often covers:

    • Locations and entities: plants, warehouses, design centers, or legal entities included in the audit
    • Processes and activities: manufacturing, maintenance, calibration, purchasing, design, software validation, document control, etc.
    • Products and services: product families, part ranges, or service types that fall under the audit
    • Time period: the timeframe of records to be sampled (for example, the last 12 months of production)
    • Standards and criteria: the specific regulations, customer specifications, or management system standards being assessed (for example, ISO 9001, AS9100, IATF 16949, regulatory rules)
    • Systems and data: which IT/OT systems are in scope (MES, ERP, QMS, document control, maintenance systems) and related interfaces

    For certification or compliance audits, the audit scope is typically documented in the audit plan and on the certificate itself, and is agreed in advance between the auditee and the auditing body.

    Operational meaning in manufacturing

    In manufacturing operations, audit scope helps determine:

    • Which production lines, cells, or maintenance areas auditors will visit
    • Which records, logs, and data sets (for example, batch records, travelers, NCs, CAPAs, calibration records) must be prepared
    • Which suppliers, outsourced processes, or logistics flows need to be included
    • Which digital systems and integrations (for example, MES to ERP interfaces, data historians, PLM links) must be available for review

    When organizations maintain multiple schemes (for example, ISO 9001 plus AS9100 or IATF 16949), each certification or regulatory program can have its own audit scope and may involve separate sites, processes, and system boundaries. This affects planning, documentation, and the number and type of audits that must be performed.

    What audit scope is not

    Audit scope is related to, but distinct from:

    • Audit objectives: why the audit is being performed (for example, certification, surveillance, supplier qualification, internal process check)
    • Audit criteria: the specific requirements used as the benchmark (standards, procedures, contracts, regulatory clauses)
    • Audit plan or schedule: the timing, agenda, and sequence of audit activities

    Audit scope sets the boundary of what is examined; it does not define the detailed audit checklist or sampling method.

    Common confusion

    • Audit scope vs. organizational scope of certification: The scope of certification describes what the organization is certified for (for example, design and manufacture of aerospace components). An individual audit's scope might be narrower, covering only one site or subset of processes at a given time.
    • Audit scope vs. risk scope: Risk assessments may consider a wide range of potential issues, while an audit scope may intentionally focus on a subset of those areas, such as special processes or high-risk suppliers.

    Link to the derived context

    When moving between or adding standards such as ISO 9001, AS9100, or IATF 16949, organizations often need to manage expanded or overlapping audit scopes. This can mean including additional sites, processes, or regulatory interfaces in external certification audits and aligning internal audit programs so that each scheme's requirements are covered within the defined scopes.

  • control assessment

    A control assessment is a structured evaluation of how well defined controls are implemented, operating, and producing appropriate evidence. In industrial and regulated manufacturing environments, it commonly refers to assessing technical, procedural, and administrative controls related to cybersecurity, quality, safety, and compliance.

    What a control assessment includes

    In most regulated operational technology (OT) and information technology (IT) contexts, a control assessment typically covers:

    • Control design: Whether the control, as specified in policies, standards, or procedures, is suitable to address the identified risk or requirement.
    • Control implementation: Whether the control is actually deployed and configured as intended in systems, processes, and documentation.
    • Control operation: Whether the control functions consistently over time in day-to-day operations (for example, alarms triggering, access checks being applied, batch checks being executed).
    • Evidence and records: Whether logs, reports, batch records, audit trails, or other artifacts exist to demonstrate the control’s execution and traceability.

    Control assessments may be performed internally (self-assessments, internal audits) or by external parties (second-party supplier assessments, third-party audits). They can focus on cybersecurity controls, quality controls, environmental health and safety (EHS) controls, data integrity controls, or other control sets defined by standards and regulations.

    Operational context in manufacturing

    In manufacturing, a control assessment can involve examining both IT and OT layers, including:

    • Configuration and hardening of industrial control systems, HMIs, and network segments.
    • Access control and change control around MES, historians, and recipe management.
    • In-process quality checks, line clearance steps, and electronic batch record approvals.
    • Monitoring of alarms, interlocks, and safety functions, along with maintenance records.

    The assessment often relies on three basic techniques: reviewing documentation, examining configurations or process execution, and interviewing personnel responsible for the controls.

    Relation to standards and frameworks

    Many organizations base their control assessments on external frameworks and catalogs, such as cybersecurity control sets or quality system standards. For example, in information security and privacy, a control assessment may use procedures derived from a control assessment guideline that defines how to test, examine, and interview to determine control effectiveness and evidence needs. In regulated manufacturing, such documents are often used as reference models and tailored to fit legacy systems, integration constraints, and validation practices.

    What a control assessment is not

    A control assessment is not the same as:

    • A full risk assessment: A risk assessment identifies and analyzes risks. A control assessment focuses on controls that address those risks and how they perform.
    • A certification or approval: A control assessment produces findings and evidence, but does not itself guarantee compliance, certification, or regulatory acceptance.
    • A one-time test: While assessments are often periodic, they are usually part of an ongoing cycle of monitoring, remediation, and re-assessment.

    Common confusion

    The term “control assessment” is sometimes used interchangeably with:

    • Audit: An audit is typically a formal, scoped evaluation against specific requirements. A control assessment can be less formal and may be focused on control operation rather than overall system compliance.
    • Gap analysis: A gap analysis compares current practices to a target state or standard. A control assessment is more focused on the actual existence, implementation, and performance of controls, not just presence or absence.

    In practice, organizations may blend these activities, but separating the concepts helps clarify objectives and outputs.

  • 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.