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.

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

  • layered process audit

    A layered process audit commonly refers to a structured, recurring check of whether defined process steps, standard work, and key controls are being followed on the shop floor or in operational support processes. The “layered” part means the audit is performed by different levels of the organization, such as team leads, supervisors, managers, and sometimes quality or plant leadership, using aligned audit questions at different frequencies.

    In manufacturing, the term usually applies to routine verification of process discipline rather than a one-time system audit. It focuses on whether critical operating conditions are present and sustained, for example whether the right work instruction is in use, required checks are completed, tools are set correctly, materials are identified properly, and escalation steps are followed when something is out of condition.

    What it includes

    • Brief, repeated audits tied to a process, line, cell, area, or support function

    • Standardized questions or check points based on process risks or known failure modes

    • Participation by multiple management layers with defined cadence

    • Documentation of findings, follow-up actions, and closure status

    • Use as an operational control to detect drift from standard work

    It does not usually mean a financial audit, a certification audit, or a full quality management system audit. It is narrower and more operational than those activities.

    How it appears in workflows and systems

    Layered process audits may be managed on paper, in spreadsheets, or in MES, QMS, mobile audit, or digital work instruction platforms. In digital environments, an LPA program often includes scheduled audit tasks, role-based assignments, evidence capture, timestamps, exception logging, and action tracking. Results may also be reviewed alongside nonconformance, CAPA, scrap, rework, or training records to identify recurring process weaknesses.

    Common confusion

    Layered process audit is often confused with product inspection. They are related but not the same. Product inspection checks whether the output meets requirements. A layered process audit checks whether the process conditions and behaviors intended to produce conforming output are actually being followed.

    It is also commonly confused with an internal quality audit. An internal audit typically reviews broader system conformance, procedures, or compliance against an audit scope. A layered process audit is usually shorter, more frequent, and focused on day-to-day execution at the point of use.

    Manufacturing example

    On an assembly line, an operator lead might verify each shift that the current work instruction revision is posted and torque checks are recorded. A supervisor might review the same area daily for material identification and reaction-plan compliance. A manager might audit weekly for sustained adherence and closure of prior findings. Together, those checks form the layered approach.

  • How do supplier scorecards relate to the approved supplier list in AS9100?

    They are related, but they are not the same thing.

    In an AS9100 quality management system, the approved supplier list (ASL) is the controlled record of suppliers your organization has determined are acceptable for specified scopes of supply or services. Supplier scorecards are one way to monitor and evaluate ongoing supplier performance. In other words, the scorecard is typically an input to supplier approval and re-evaluation, while the ASL is the formal output of that process.

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    A supplier can be on the ASL without having a sophisticated scorecard, especially in smaller organizations or lower-volume categories, if the organization has another documented and effective method for evaluation and re-evaluation. Likewise, a supplier can have scorecard data and still remain only conditionally approved, limited by commodity, limited by program, or subject to additional controls. AS9100 does not require a specific scorecard format, threshold, or software tool.

    How they usually connect

    • Initial approval: Qualification evidence, risk review, certifications where relevant, capability assessments, trial orders, or first article results may be used before a supplier is placed on the ASL.

    • Ongoing monitoring: Scorecards often track on-time delivery, quality performance, escapes, responsiveness, corrective action closure, and other metrics defined by the organization.

    • Periodic re-evaluation: The organization reviews the evidence, including scorecard trends, and decides whether the supplier remains approved, becomes conditional, requires development, or should be removed for a given scope.

    • Controls and actions: Poor scorecard performance should trigger defined actions such as increased inspection, source inspection, CAPA, limited approval status, or sourcing restrictions, if that is what your procedure requires.

    The key point is traceability between the data you collect and the supplier status you assign. If scorecards exist but do not drive any documented review or decision-making, they add little control value.

    What AS9100 generally expects

    AS9100 is concerned with externally provided processes, products, and services being controlled using defined criteria. That usually means your organization should be able to show:

    • how suppliers are approved

    • how performance is monitored

    • how often re-evaluation occurs or what event triggers it

    • what thresholds or risk factors matter

    • who can change supplier status on the ASL

    • what records are retained as objective evidence

    A scorecard can support all of that, but it does not replace the need for a controlled supplier approval process.

    Common failure modes

    • No defined decision rule: Teams collect metrics, but no one knows what score requires escalation, conditional approval, or removal from the ASL.

    • Poor master data: Supplier names, sites, legal entities, and commodity scopes do not match across ERP, QMS, receiving, and procurement systems, so scorecard results are unreliable.

    • Scope ambiguity: A supplier may be acceptable for one process or part family but not another. A single yes or no ASL status can hide this.

    • Manual lag: Quality issues are known in NCR or receiving records, but the ASL is updated late, so buyers continue placing orders.

    • Metric distortion: A supplier meets delivery metrics by shipping partial quantities or low-risk work first, while quality performance deteriorates.

    • No change control: Supplier status changes happen by email or spreadsheet without review history, approval traceability, or effective dates.

    These problems are common in brownfield environments because supplier data and performance signals often live across ERP, QMS, supplier portals, spreadsheets, and email. If those systems are not aligned, scorecards can look precise while the ASL process remains weak.

    Brownfield system reality

    In many regulated plants, the ASL is maintained in one system, purchasing transacts in ERP, supplier NCRs sit in QMS, and delivery performance is calculated from receiving or planning data. That coexistence can work, but only if ownership, data mapping, and update timing are explicit.

    Trying to replace all supplier, quality, and ERP workflows at once is often a bad strategy in long-lifecycle regulated environments. The qualification burden, validation cost, downtime risk, and integration complexity are usually high, and the result can be weaker traceability during transition. A more practical approach is often to preserve the system of record for the ASL, connect scorecard inputs from adjacent systems, and put formal review and change control around status decisions.

    So the practical answer is: supplier scorecards should inform the approved supplier list, but your documented process must define exactly how. If that linkage is vague, manual, or inconsistent across systems, you should not assume the scorecard by itself demonstrates effective supplier control.

  • scope

    In industrial and regulated manufacturing environments, scope is the formally defined boundary of what a system, project, or activity covers. It specifies what is included, what is excluded, and the conditions under which the defined elements apply.

    Scope in management systems and standards

    In management system standards (such as many ISO standards), scope commonly refers to the boundary of the management system. This typically includes:

    • Sites, locations, and organizational units covered
    • Activities, processes, and value streams included
    • Products, services, or product families in scope
    • Interfaces with other functions or organizations
    • Defined exclusions and their justification

    In regulated manufacturing, the declared scope is expected to match operational reality, be supported by evidence (such as process maps, system inventories, and organizational charts), and be controlled under change management when boundaries change.

    Scope in projects and systems

    In projects, IT/OT programs, or system implementations, scope describes which objectives, deliverables, and work are included. For example:

    • An MES deployment may define scope in terms of plants, lines, products, and process stages it will cover.
    • An ERP integration project may specify which data objects, transactions, and interfaces are in scope.
    • A validation effort may define the scope of functions, configurations, and risks that must be assessed.

    Clear scope definition helps distinguish between core project work and items that are explicitly out of scope or deferred.

    Operational use of scope

    Operationally, scope often appears in:

    • Policies and procedures: describing which processes, roles, and facilities the document applies to.
    • Quality management documents: defining which products, lots, or processes are covered by a specification or control plan.
    • System records and configurations: indicating which assets, data sources, or workflows are monitored, controlled, or governed.
    • Audits and assessments: setting the boundary of what the audit will examine and which requirements will be applied.

    Common confusion

    Scope vs. requirements: Scope describes the boundary (what is covered); requirements describe what that boundary must achieve or satisfy. A system can be in scope for a standard while specific requirements within that standard apply differently to parts of the scope.

    Scope vs. objective: Scope defines where and to what the work or system applies; objectives define what results are intended within that scope.

    Link to ISO-related usage

    In ISO-style management system standards, scope commonly refers to the formally documented boundary of the management system. It is typically described in a scope statement, covering applicable locations, activities, products or services, and justified exclusions. In manufacturing environments, this scope statement is expected to align with real operations and be maintained under document control and change management.

  • Code of Practice

    A code of practice is a documented set of recommended practices, rules, and minimum expectations for how specific activities should be carried out and controlled. In industrial and regulated manufacturing environments, it commonly refers to guidance issued by industry bodies, regulators, or companies themselves to standardize safe, compliant, and consistent operations.

    Core characteristics

    A code of practice typically:

    • Addresses a defined topic, process, or risk area, such as machine safety, lockout/tagout, data integrity, or hygienic manufacturing
    • Describes practical methods and controls for meeting high-level legal, regulatory, or policy requirements
    • Is usually written as guidance or recommended practice, not as law, although it may be referenced by regulations or contracts
    • Provides a common reference for training, audits, and operational procedures

    In an individual company, a code of practice can be an internal governance document that sets out how employees and contractors must perform certain tasks, often sitting above detailed work instructions and standard operating procedures (SOPs).

    Use in industrial and manufacturing environments

    Within industrial operations, codes of practice commonly apply to:

    • Health, safety, and environment (HSE), such as hazardous materials handling, confined space entry, or emergency response
    • Quality and GMP-related activities, such as cleaning, contamination control, or data recording in MES and quality systems
    • OT and IT practices, including cybersecurity controls, access management, and configuration management for production systems
    • Equipment use and maintenance, such as calibration, lockout/tagout, or guarding standards
    • Information management, document control, and record retention for regulated operations

    Operationally, codes of practice influence how procedures are written, how MES/ERP workflows are configured, how training is structured, and how internal audits or inspections assess adherence to company and industry expectations.

    Relationship to laws, standards, and procedures

    A code of practice often sits between high-level requirements and day-to-day instructions:

    • Laws and regulations define mandatory requirements at a high level.
    • Standards (for example, those published by industry or standards bodies) provide structured frameworks and terminology.
    • Codes of practice translate these into topic-specific, practical guidance and expected behaviors.
    • SOPs and work instructions provide step-by-step instructions tailored to a site, process, or machine.

    In some jurisdictions, complying with an officially recognized code of practice may be considered one accepted way to demonstrate that legal obligations are being addressed, although alternative approaches can exist. Internal company codes of practice may be mandatory under company policy even if they are not legal instruments.

    Common confusion

    • Code of practice vs. standard: A standard usually defines common technical or management requirements and terminology. A code of practice is more focused on how to apply requirements in practice in a specific area.
    • Code of practice vs. SOP: An SOP gives detailed, step-by-step instructions for a particular task or process at a site. A code of practice is higher level, describing principles, required controls, and general methods that multiple SOPs might implement.
    • Code of practice vs. code of conduct: A code of conduct focuses on ethical and behavioral expectations for people. A code of practice focuses on how processes and activities should be carried out and controlled.

    Context in regulated operations

    In regulated manufacturing, codes of practice may influence how companies design quality systems, document control, training programs, and system configurations. They are frequently referenced during internal and external audits as evidence of an organization’s approach to managing specific risks, though they do not themselves constitute proof of compliance.

  • Change Impact Assessment

    Change Impact Assessment commonly refers to a structured evaluation of the potential effects of a proposed change before the change is approved or implemented. In regulated manufacturing and industrial operations, it is used to identify what the change could affect, how significant those effects may be, and what follow-up actions may be needed.

    The term usually applies to changes involving processes, equipment, software, documents, materials, specifications, workflows, data flows, or organizational responsibilities. It includes considering impacts on product quality, process performance, validated or controlled systems, training, documentation, traceability, and downstream operations. It is not the same as making the change itself, and it is not limited to technical risk alone.

    What it typically covers

    • The scope of the proposed change and what is being modified

    • Which products, lines, assets, records, or sites may be affected

    • Potential effects on quality, safety-related controls, compliance obligations, and customer requirements

    • Effects on connected systems such as MES, ERP, PLM, historians, SCADA, or quality systems

    • Whether procedures, work instructions, specifications, or training records need updates

    • Whether testing, verification, requalification, or revalidation may be required

    • Whether implementation should include approvals, staged rollout, or post-change review

    Operational meaning

    In practice, a Change Impact Assessment is often part of formal change control. A team documents the proposed change, identifies affected functions and records, rates impact or risk, and records required actions before execution. For example, changing a machine parameter recipe, revising an electronic batch record workflow, or updating an MES to ERP interface may each require an assessment of operational, quality, and data integrity impacts.

    Common confusion

    Change Impact Assessment is often confused with risk assessment, change control, and validation.

    • Risk assessment focuses on the likelihood and severity of harm or failure. A Change Impact Assessment may include risk considerations, but it is broader and asks what areas are affected.

    • Change control is the overall process for requesting, reviewing, approving, implementing, and closing a change. The assessment is one component of that process.

    • Validation or qualification assessment focuses specifically on whether a system, process, or equipment must be tested or requalified. That can be an outcome of the impact assessment, not the full definition of it.

    Why the term matters in manufacturing systems

    In integrated manufacturing environments, one change can affect multiple records and systems at once. A seemingly local update, such as changing part master data, a workflow step, or a work instruction, may also affect planning logic, device interfaces, genealogy records, reporting, or training requirements. Change Impact Assessment provides a documented way to identify those dependencies before implementation.

  • What evidence do auditors typically look for under AS9100 Rev D?

    Auditors under AS9100 Rev D are looking for objective evidence that your quality management system (QMS) is defined, implemented as documented, under control, and effective. The specific evidence will vary by organization and audit scope, but it typically clusters around the following areas.

    1. Context, scope, and leadership

    • Documented scope of the QMS and applicability of clauses.
    • Quality policy and measurable quality objectives that align with customer and regulatory requirements.
    • Evidence of management commitment, such as management review records, agendas, minutes, and resulting actions.
    • Documented organizational roles, responsibilities, and authorities.

    2. Documented information and configuration control

    • Document control procedures that address creation, review, approval, distribution, revision, and obsolescence.
    • Controlled procedures, work instructions, specifications, and quality plans that are current and available at the point of use (paper or digital).
    • Evidence of configuration management for product definition data, including engineering changes, ECNs/ECOs, and configuration baselines.
    • Change control records that show impact assessment, approvals, and implementation tracking across affected functions and systems (ERP, MES, PLM, QMS).

    3. Risk-based thinking and operational risk management

    • Evidence of risk assessment and mitigation for products and processes, including documented methods and risk registers where applicable.
    • Integration of risk into planning, such as special process controls, additional inspections, or supplier controls driven by risk.
    • Records showing periodic review of risks, changes in risk ratings, and actions taken.
    • Evidence that risk considerations are used in decisions about changes, nonconformities, and improvement priorities.

    4. Contract review and requirements management

    • Contract, PO, and customer requirement review records, including technical, quality, and delivery requirements.
    • Evidence that flowed-down customer and regulatory requirements are captured, analyzed, and translated into internal documentation and work instructions.
    • Change management records for contract changes, including communication with customers and internal updates.
    • Evidence of handling of ambiguous, conflicting, or missing requirements and corresponding customer clarifications.

    5. Design and development (when in scope)

    • Design and development planning, including responsibilities, stages, and reviews.
    • Design inputs, design outputs, and their traceability to requirements.
    • Design review, verification, and validation records, including test plans, reports, and approvals.
    • Configuration management of design data across tools (e.g., CAD, PLM, ERP, MES) and evidence of change control.
    • Evidence that design changes are evaluated for impact on production, inspection, suppliers, and fielded product.

    6. Purchasing and supplier control

    • Approved supplier list and criteria for selection, evaluation, and re-evaluation.
    • Supplier performance data (OTD, quality, escapes) and actions taken when performance degrades.
    • Purchase orders showing proper flowdown of technical, quality, and regulatory requirements, including special process approvals where applicable.
    • Evidence of control for outsourced processes, including agreements, certifications, and surveillance where needed.
    • Receiving inspection and verification records, including handling of discrepancies and supplier nonconformances.

    7. Production, inspection, and process control

    • Documented process controls, routers/travelers, and work instructions that match what operators actually do.
    • Evidence that the latest revisions of drawings, specifications, and instructions are in use at each workstation.
    • Process capability, setup verification, and first-piece/first-article inspection records (including AS9102 where applicable).
    • Records demonstrating control of special processes, including qualification, periodic verification, and operator certification.
    • Inspection and test records showing that defined characteristics, sampling plans, and acceptance criteria were applied.
    • Evidence of control over rework, repair, concessions/deviations, and associated approvals.

    8. Identification, traceability, and preservation

    • Evidence of lot/serial number tracking and linkage to materials, processes, inspections, and test results.
    • Marking and labeling practices that align with specifications and customer requirements.
    • Records supporting material certifications, CoCs/CoAs, and their linkage to specific parts or lots.
    • Evidence of control of customer property, calibrated tooling, and key inspection assets.
    • Procedures and records for handling, storage, packaging, preservation, and delivery to prevent damage and degradation.

    9. Nonconformance, corrective action, and problem solving

    • Nonconformance reports (NCRs) covering detection, segregation, disposition, and communication.
    • Material review board (MRB) records, including risk assessment and customer/regulatory approvals when required.
    • Corrective action and preventive action (CAPA) records demonstrating root cause analysis, containment, corrective actions, verification of effectiveness, and closure.
    • Evidence that recurring issues are identified, escalated, and addressed at the system level, not just at the incident level.
    • Trend data and analysis used to prioritize corrective actions and improvement projects.

    10. Internal audits and management review

    • Internal audit program, schedule, and risk-based rationale for audit frequency and scope.
    • Internal audit reports, objective evidence collected, and documented nonconformities or observations.
    • Corrective actions resulting from internal audits and evidence that they were implemented and verified.
    • Management review inputs and outputs, including performance data, risks, opportunities, and decisions or actions.

    11. Competence, awareness, and training

    • Defined competence requirements for key roles, including operators, inspectors, special process personnel, and auditors.
    • Training records, qualifications, and certifications (e.g., special processes, NDT, inspection qualifications).
    • Evidence that personnel are aware of the quality policy, their contribution to product conformity and safety, and the implications of nonconformance.
    • Evidence that training effectiveness is evaluated, not just that training events occurred.

    12. Data use, performance monitoring, and continual improvement

    • Defined KPIs and performance measures for quality, delivery, and process performance.
    • Monitoring and analysis records, including trends, dashboards, or reports used in routine reviews.
    • Evidence that data is used to prioritize improvement actions, resource allocation, and risk mitigation.
    • Records of improvement projects, kaizen events, or process changes and how their effectiveness was assessed.

    Brownfield and systems reality

    In most aerospace environments, evidence is scattered across legacy ERP, MES, PLM, QMS tools, local databases, spreadsheets, and paper travelers. Auditors are less concerned about which system you use and more about whether:

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    • The records are complete, accurate, and consistent across systems.
    • You can retrieve the right evidence quickly, with clear traceability.
    • Changes are controlled and synchronized so that operators do not work to obsolete data.
    • There is a clear audit trail showing who did what, when, and under what revision.

    Full rip-and-replace of core systems solely for audit readiness is rarely practical in regulated, long-lifecycle aerospace operations due to validation burdens, downtime risk, and integration complexity. Incremental improvements to evidence capture, data integrity, and traceability within the existing stack are more common and generally lower risk.

    Key constraint: evidence depends on your actual processes

    The exact evidence auditors expect will depend on:

    • Whether design is in scope or excluded.
    • Your product mix, special processes, and regulatory environment.
    • The maturity and integration level of your current systems and records.
    • Customer-specific requirements and additional flowdowns.

    For planning, assume auditors will sample across processes and expect to see records that connect requirements, risk, execution, inspection, nonconformance handling, and management actions in a coherent, traceable way.

  • Layered Process Audits (LPA)

    Layered Process Audits (LPA) are a structured audit approach in which different levels of an organization routinely check that critical process steps are being followed as defined. LPAs focus on verifying adherence to standard work and controls on the shop floor rather than re-checking final product quality.

    What Layered Process Audits include

    LPAs commonly involve:

    • Short, high-frequency audits (often daily or weekly) performed at the point of work
    • Standardized checklists that target a small number of high-risk or high-priority process controls
    • Multiple organizational “layers” participating, such as operators, team leads, supervisors, engineers, and managers
    • Direct observation of work practices, tooling, materials, documentation, and safety or regulatory controls
    • Immediate recording of findings, correction of issues when possible, and logging of nonconformities for follow-up

    In regulated manufacturing environments, LPAs are often integrated with quality management systems, MES, or digital work instruction platforms so that checklists, evidence (signatures, timestamps, photos), and follow-up actions are captured in a traceable way.

    How LPAs are used in operations

    Operationally, Layered Process Audits:

    • Check that standard work, control plans, work instructions, and safety requirements are followed as written
    • Verify that critical conditions are in place, such as correct tooling, machine settings, calibrated gages, and material identification
    • Provide a routine mechanism for leaders to see real process conditions across shifts and lines
    • Feed issues into existing nonconformance, CAPA, or continuous improvement workflows
    • Support internal audit readiness for standards such as ISO 9001 or AS9100 by maintaining ongoing evidence of process discipline

    LPAs are distinct from one-time system or certification audits; they are intended to be part of daily management and operational routines.

    What Layered Process Audits are not

    • They are not full system audits of the entire quality management system or regulatory framework.
    • They are not detailed product inspections or full measurement programs, although they may verify that inspection steps are being performed.
    • They are not limited to safety checks; they typically cover quality, process stability, and compliance-related steps as well.

    Common confusion

    • Internal process audits vs. LPAs: Internal process audits are usually longer, less frequent, and broader in scope (for example, checking a complete process area against a standard). LPAs are shorter, more frequent, and focused on a defined set of key checks.
    • Product audits vs. LPAs: Product audits inspect finished or in-process product against specifications. LPAs verify that the process used to make the product is followed and controlled.

    Relation to production system health

    In the context of monitoring production system health, LPA results can be used as a metric for process discipline and system integrity. Trends in LPA compliance, findings, and closure rates can indicate whether processes are stable and whether standards are consistently applied across shifts, lines, and sites.