Connect981 – Content Dev

RSC Content Type: Definitive Guide

Deep educational pillar explaining a complex domain end-to-end.

  • How do you prove characteristic accountability during an audit?

    Proving characteristic accountability means demonstrating that every required characteristic from a drawing or specification is traced to a specific operation, inspection, and result, with no gaps. Auditors are looking for evidence that you know where each characteristic is made, where it is verified, and how nonconformities are handled, under effective document control.

    1. Start from the source: requirements and ballooning

    Most audits begin with the design or customer requirement:

    • Current, approved drawing or specification under document control.
    • Ballooned drawing or characteristics map (for FAI/AS9102 and similar contexts).
    • Characteristic list (CL) or index linking each balloon/ID to a requirement (dimension, note, spec, KPC/CTQ, etc.).

    To prove accountability, you must show that every characteristic on that list is accounted for in your routing, work instructions, or inspection plan. Any missing or ambiguous mapping is a typical audit finding.

    2. Map each characteristic to an operation and method

    The next expectation is a clear link from characteristic to process step:

    • Routing or traveler that lists operations where the characteristic is created or affected (e.g., machining, heat treat, coating, assembly).
    • Work instructions or control plans identifying how the characteristic is produced and controlled (e.g., tooling, fixturing, SPC, special process controls).
    • Inspection plan that shows how and where each characteristic is verified (100% vs sample, in-process vs final, gage type, method).

    For an auditor, characteristic accountability is often tested by picking a balloon number at random and asking you to show, without gaps:

    • Where in the routing it is made/affected.
    • Which work instruction step or control addresses it.
    • Where the inspection or verification is planned and recorded.

    3. Provide objective evidence: inspection and test records

    Traceability requires objective records, not just plans. Typical evidence includes:

    • FAI forms (e.g., AS9102 Form 3), linked to ballooned characteristics.
    • In-process and final inspection reports tied to specific operations.
    • Electronic inspection data (CMM output, SPC charts) with clear characteristic IDs.
    • Gage IDs, calibration status, and operator signoffs for each measurement step.

    To prove accountability, the record must allow you to answer, for any characteristic:

    • Who inspected it (or what system did the check).
    • When it was checked (lot, work order, date/time).
    • What the result was (pass/fail, measured value).
    • What happened when it did not meet requirements (NCR/MRB, disposition, rework).

    4. Show nonconformance and disposition linkage

    Auditors will also test accountability with defects:

    • Nonconformance records that reference the characteristic ID, drawing balloon, or requirement.
    • MRB and disposition records (use-as-is, repair, scrap, rework) tied to the specific work order / serials.
    • Evidence that re-inspection or validation occurred after rework/repair.

    If you cannot map a nonconformance back to a specific characteristic and forward to the affected units, your characteristic accountability will be considered weak.

    5. Maintain configuration control and revision traceability

    In regulated and aerospace environments, auditors also expect you to prove which requirements applied at the time of manufacture:

    • Document control showing which drawing/spec revision was active for each lot or serial number.
    • Change control records for when characteristics were added, removed, or reclassified (e.g., KPC, safety-critical).
    • Updated ballooning and characteristic lists when the design or spec changes.

    Without configuration control, you might have good inspection records that no longer match the current drawing, which undermines your evidence during an audit.

    6. Digital vs paper: brownfield system realities

    Most plants have mixed systems: ERP, MES, PLM, QMS, plus spreadsheets and paper. Auditors will care less about whether it is digital or paper and more about whether the links are:

    • Complete: no orphan characteristics with no assigned control or inspection.
    • Consistent: IDs match between drawing, plans, and records.
    • Traceable: they can follow a characteristic from requirement to result quickly.
    • Controlled: revisions and changes are documented and approved.

    If you use multiple systems (common in brownfield environments), you will need a clear integration or at least a documented cross-reference to show, for example:

    • Drawing/balloon numbers from PLM linked to operation and inspection steps in MES/ERP.
    • Inspection results in an SPC or CMM system mapped back to the same characteristic IDs.
    • NCR records in QMS referencing the same characteristic codes and work orders.

    Full system replacement purely to improve characteristic accountability is rarely practical in aerospace-grade contexts due to validation effort, qualification, integration risk, and downtime. Incremental improvements (e.g., a digital inspection layer or better characteristic mapping tools) are usually more realistic and auditable if implemented under change control.

    7. Common audit failure modes for characteristic accountability

    Typical gaps that auditors flag include:

    • Characteristics on the drawing that are missing from control/inspection plans.
    • Balloon numbers that do not match between the drawing, FAI, and inspection sheets.
    • Special / safety-critical / key characteristics not clearly identified or treated differently.
    • Inspection records that show generic feature descriptions without a clear link to the characteristic ID.
    • Reworked characteristics without evidence of re-inspection and acceptance.
    • No evidence of which revision of the drawing/spec was used for a given batch.

    8. Practical steps to strengthen your evidence before an audit

    To improve your ability to prove characteristic accountability:

    • Perform an internal review where you pick random characteristics and walk the full chain: drawing → characteristic list → routing/operation → work instruction → inspection plan → inspection record → NCR (if any).
    • Standardize characteristic IDs and ensure they are used consistently across all systems.
    • Ensure FAI/AS9102 packages are complete, with clear balloon-to-result mapping, and kept accessible.
    • Close gaps where certain notes, surface finishes, or specification references are not explicitly inspected or controlled.
    • Put changes under formal change control, including updates to ballooning, CLs, travelers, and inspection plans.

    The goal is that, when an auditor points to any characteristic, you can show a clear, documented, and controlled path from requirement to evidence without scrambling across multiple systems or relying on tribal knowledge.

  • What information should an aerospace supplier portal expose to suppliers?

    An aerospace supplier portal should expose the information suppliers need to perform work correctly, respond to changes, and provide required evidence back to the customer. It should not expose everything your internal teams can see.

    In practice, the portal should provide a controlled supplier-facing view of current requirements, transaction status, quality obligations, and exception workflows. The exact scope depends on contract structure, export control boundaries, technical data restrictions, program sensitivity, supplier tier, and how reliably your ERP, PLM, MES, QMS, and document systems stay synchronized.

    What suppliers usually need to see

    • Purchase order and line details
      PO number, part number, revision, description, quantities, due dates, ship-to location, applicable clauses, outside processing instructions, and any customer-specific requirements tied to the order.

    • Approved engineering and manufacturing documents
      Only the documents the supplier is authorized to access, with clear revision status, effectivity, release date, and withdrawal of obsolete versions. If document control is weak, the portal can spread bad data faster rather than solve the problem.

    • Quality and inspection requirements
      Required certs, FAI expectations, key characteristics, sampling or inspection instructions where applicable, approved special process requirements, approved sources, and evidence package expectations at receipt or shipment.

    • Change notifications
      Supplier-visible change notices affecting current work, including revision changes, requirement clarifications, date changes, disposition instructions, and whether work in process is affected. This must be tightly governed. Uncontrolled change messaging creates traceability problems and commercial disputes.

    • Delivery, shipment, and receiving status
      Requested dates, commits, ASNs if used, receipt status, acceptance or rejection status, shortages, and open actions. This is often more valuable than a generic supplier scorecard because it helps the supplier act on the current order.

    • Nonconformance and disposition workflows
      Visibility into supplier-related NCRs, holds, containment requests, response due dates, disposition status, and required corrective action submissions. Access should be scoped carefully so suppliers only see records relevant to their own material and obligations.

    • Performance and compliance tasks
      Open acknowledgments, required training or policy attestations if contractually required, expired certifications, questionnaire status, and supplier onboarding tasks.

    • Communication and evidence exchange
      A structured channel for submitting certs, test reports, FAI packages, deviation requests, acknowledgments, and corrective action responses. Email-only processes usually become an audit trail problem in regulated environments.

    What should usually stay limited or abstracted

    • Internal-only planning detail
      Detailed internal routings, margin data, internal capacity assumptions, unrelated inventory positions, or customer-sensitive downstream program data usually should not be exposed unless there is a specific operational reason.

    • Unreleased or draft documents
      Do not expose draft revisions, informal redlines, or pending engineering changes as if they are executable requirements.

    • Cross-supplier visibility
      Suppliers generally should not see other suppliers’ performance, sourcing structures, or program issues.

    • Broad system access disguised as a portal
      A portal is not a safe substitute for role-based data governance. If access rules are weak, a supplier portal can become a leakage path for controlled technical data.

    Design principles that matter more than feature count

    • Revision certainty
      Suppliers need confidence that what they see is the current approved requirement. If PLM, ERP, QMS, and document repositories disagree, the portal should show the system of record or clearly identify source and status.

    • Traceable acknowledgments
      For changed requirements, date commits, and quality actions, capture who acknowledged what and when.

    • Role-based access
      Access should be segmented by supplier, site, program, commodity, and data classification as needed.

    • Structured transactions over free text
      Shipment notices, concessions, document submissions, and corrective actions work better as structured workflows than as message attachments.

    • Exception visibility
      Suppliers should see open blockers, missing documents, rejected lots, and overdue actions. A portal that only shows static order data does not help much.

    Brownfield reality

    Most aerospace supplier portals sit on top of mixed ERP, PLM, MES, QMS, document control, and file-sharing tools. That means the portal often reflects integration quality more than portal design.

    If master data is inconsistent, document release is slow, supplier identities are duplicated, or nonconformance workflows are split across systems, the portal will expose those weaknesses. In many plants, a phased supplier-facing layer is safer than trying to replace core systems. Full replacement strategies often fail because qualification and validation take too long, downtime windows are limited, integrations are deeply embedded, and long asset lifecycles make cutover risk hard to justify.

    Practical minimum set

    If you need a starting point, expose this first:

    • current PO status and required acknowledgments

    • controlled document access with revision and effectivity

    • shipment and receipt status

    • quality document submission and status

    • supplier NCR and corrective action workflow

    • change notices affecting open work

    Then add broader planning visibility, scorecards, and collaboration workflows only after data ownership, change control, and access governance are stable.

    The short answer is: expose enough for correct execution and traceable response, but only through controlled, role-based, revision-aware views. More visibility is not automatically better in a regulated aerospace supply chain.

  • digital nonconformance management

    Digital nonconformance management is the use of software-based workflows and records to identify, document, evaluate, contain, disposition, and close nonconformances. In manufacturing, this commonly refers to replacing paper, spreadsheets, email chains, or disconnected logs with a controlled digital process for handling products, materials, processes, or documentation that do not meet defined requirements.

    The term usually covers the operational handling of a nonconformance record from detection through review and resolution. That can include defect capture, segregation or hold status, assignment, investigation, disposition, approvals, rework or scrap tracking, and links to corrective action when needed. In connected environments, it may also include integration with MES, ERP, QMS, PLM, inspection systems, and traceability records so the nonconformance is tied to the affected part, lot, serial number, work order, supplier, or operation.

    Digital nonconformance management is not the same as CAPA, although the two are often connected. Nonconformance management focuses on handling specific instances of nonconforming output. CAPA focuses more broadly on root cause, corrective action, and prevention of recurrence when escalation is required. It is also distinct from MRB itself; MRB is a review or disposition function, while digital nonconformance management is the broader system and workflow used to manage the record and process around the event.

    This term is commonly used in regulated or quality-sensitive operations where evidence, traceability, role-based approvals, and audit trails matter. A typical example is an operator or inspector logging a dimension out of tolerance in a digital NCR workflow, after which the record is routed for review, linked to the affected traveler and serial number, and tracked through disposition and closure.

  • NIST SP 800-171A

    Core meaning

    NIST SP 800-171A is a U.S. National Institute of Standards and Technology (NIST) Special Publication that provides standardized assessment procedures for the security requirements defined in NIST SP 800-171 (Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations).

    It describes how to assess whether an organization’s controls meet the NIST SP 800-171 requirements, including:

    – Objectives and assessment methods for each security requirement
    – Types of evidence an assessor may review
    – How to determine and record assessment findings (satisfied, partially satisfied, not satisfied)

    The document itself is guidance. It is used as a reference model for organizing and performing assessments, rather than a control catalog.

    Use in industrial and manufacturing environments

    In regulated manufacturing and industrial operations, NIST SP 800-171A is commonly used to:

    – Structure internal or third-party assessments of cybersecurity controls around Controlled Unclassified Information (CUI)
    – Provide a repeatable method to evaluate technical and procedural safeguards implemented in OT and IT systems
    – Support documentation of assessment results for customers, primes, or government agencies that expect alignment with NIST SP 800-171

    Organizations that handle CUI in MES, ERP, quality systems, data historians, or other OT/IT assets may use 800-171A to:

    – Define assessment steps for access control, system and communications protection, audit logging, and incident response
    – Collect objective evidence (configurations, logs, procedures, records) from production systems and supporting infrastructure

    Scope boundaries

    NIST SP 800-171A:

    – **Includes**: Assessment objectives and example procedures for each NIST SP 800-171 requirement across control families such as Access Control, Configuration Management, Incident Response, and System Integrity.
    – **Excludes**: Defining the underlying security requirements themselves (those are in NIST SP 800-171); defining legal or contractual obligations; prescribing specific technologies or vendors.

    It is not an implementation guide for how to configure specific products, and it is not an official certification scheme. Instead, it provides a consistent method to check and document how well implemented measures align with NIST SP 800-171.

    Relationship to NIST SP 800-171 and other frameworks

    – **NIST SP 800-171**: Defines what protections are required for CUI in nonfederal systems.
    – **NIST SP 800-171A**: Defines how to assess whether those protections are in place and effective.

    In many organizations, 800-171A assessment results feed into broader risk management, self-attestation, or customer-required security documentation. In U.S. defense supply chains, its structure often underpins assessments that are later mapped to other scoring or reporting schemes.

    Common confusion and correct usage

    – **Not the same as NIST SP 800-171**: 800-171 is the requirement set; 800-171A is the assessment guidance. References to “implementing 800-171A” are typically inaccurate; the correct phrasing is “assessing against 800-171A procedures.”
    – **Not a certification standard**: Using 800-171A does not by itself constitute a formal certification or authorization. It is a method to organize and document assessments.
    – **Different from NIST SP 800-53**: 800-53 is a broader control catalog for federal systems. 800-171 and 800-171A are tailored to nonfederal environments handling CUI.

    Site context: application to manufacturing systems

    Within manufacturing, NIST SP 800-171A is frequently applied to:

    – Assess security controls around CUI stored or processed in MES, QMS, ERP, PLM, and document management systems
    – Evaluate access control and logging on shop-floor OT assets that interact with CUI (e.g., NC programs, product configurations, electronic work instructions)
    – Structure evidence collection from production networks, engineering workstations, and data transfer mechanisms between design, planning, and plant systems

    Its structured assessment objectives help align cybersecurity evaluations across IT and OT domains in plants that support defense or other CUI-related programs.

  • Information Security Management System

    An Information Security Management System (ISMS) is a structured management framework that an organization uses to direct and control how it protects information. It covers the governance, policies, processes, resources, and controls that define how information security is planned, implemented, monitored, reviewed, and improved.

    In practice, an ISMS typically includes:

    • Defined scope for the information, locations, systems, and activities it covers
    • Information security policies, roles, and responsibilities
    • Risk assessment and risk treatment processes for information assets
    • Documented operational and technical controls for confidentiality, integrity, and availability
    • Procedures for incident reporting, response, and corrective actions
    • Ongoing monitoring, internal audit, and management review activities
    • Processes for continual improvement of the security controls and governance

    Standards such as ISO/IEC 27001 define formal requirements for establishing, implementing, maintaining, and continually improving an ISMS.

  • System Security Plan (SSP)

    A System Security Plan (SSP) is a formal document that describes how security requirements are implemented, managed, and maintained for a specific information system or environment. In regulated and industrial settings, it is typically used to document how a manufacturing, OT, MES, or related IT system meets defined cybersecurity and compliance requirements.

    What a System Security Plan includes

    While formats vary by framework and organization, an SSP commonly documents:

    • System description and boundaries: Purpose, functions, system components, data flows, and connections to other systems or networks, including OT/IT interfaces.
    • Applicable security requirements: Referenced standards or frameworks (for example, NIST SP 800-53, NIST SP 800-171, or corporate policies).
    • Control implementation details: How each required control is implemented or addressed, including technical, administrative, and physical safeguards.
    • Roles and responsibilities: Who is responsible for implementing, operating, and monitoring each control, including shared responsibilities with cloud or service providers.
    • System environment and dependencies: Operating systems, applications, cloud services, OT equipment, and supporting infrastructure the system relies on.
    • Configuration and baseline information: References to secure configurations, hardening guides, or baseline settings relevant to the system.
    • Continuous monitoring and maintenance: How security is monitored, how changes are controlled, and how issues are tracked and remediated.

    Use in regulated manufacturing environments

    In manufacturing and industrial operations, a System Security Plan commonly applies to:

    • Manufacturing execution systems (MES) and production control systems.
    • OT networks, SCADA/PLC environments, and data historians.
    • Quality and laboratory systems (for example, LIMS, QMS platforms).
    • Cloud-hosted applications supporting production, quality, or supply chain processes.

    Organizations use SSPs to demonstrate how security controls are applied in practice, to support audits and assessments, and to coordinate security responsibilities among internal IT/OT teams, vendors, and cloud providers.

    Relationship to frameworks like NIST SP 800-53

    In the context of NIST-based programs, the SSP is the central document that maps required controls (for example, those derived from NIST SP 800-53) to specific implementations in the system. When cloud or external providers are involved, the SSP typically:

    • Identifies which controls are implemented by the provider.
    • Identifies which controls are shared and require customer configuration.
    • Identifies which controls remain entirely the responsibility of the organization operating the manufacturing or OT system.

    The SSP often references provider documentation such as security packages, control responsibility matrices, and configuration baselines, but it remains the organization’s document that describes the end-to-end system.

    Common confusion

    • Not just a policy document: An SSP is more detailed and system-specific than a high-level security policy. It focuses on how controls are applied to a particular system or environment.
    • Not a certification: An SSP by itself does not indicate certification or approval. It is an input to assessments, authorizations, or audits.
    • Not a vendor security whitepaper: Vendor or cloud security documentation can be referenced in an SSP, but does not replace the need for an SSP that covers the complete system boundary and local responsibilities.

    Operational role

    Operationally, a System Security Plan serves as a reference for:

    • Onboarding new team members to the security characteristics of a production or OT system.
    • Planning and documenting security changes or upgrades.
    • Supporting internal reviews, risk analyses, and external audits of manufacturing and quality systems.
    • Coordinating with vendors and service providers on shared security responsibilities.

  • bill of materials

    Core meaning

    A **bill of materials** (BOM) is a structured list that specifies all components, raw materials, subassemblies, and sometimes services required to manufacture a defined product or execute a defined batch, including their quantities and basic identifying information.

    In industrial and regulated manufacturing environments, the BOM commonly:

    – Is defined and maintained in ERP, PLM, or product definition systems
    – Includes material identifiers, descriptions, units of measure, and required quantities
    – References engineering or product revisions to tie materials to a specific version of the product
    – Serves as a reference for planning, procurement, inventory management, and production execution

    A BOM describes **what** is needed to build a product, not **how** or **when** work is performed.

    Typical structure and levels

    BOMs are often hierarchical and may include:

    – **Top-level (finished good) BOM**: Lists main subassemblies and key materials that make up the final product
    – **Subassembly BOMs**: Define components for intermediate assemblies used within the top-level product
    – **Phantom or logical BOMs**: Groupings used for planning or design that may not exist as separate stocked items

    Depending on system and practice, BOMs may also identify alternates or substitutes, packaging materials, and labeling components when they are explicitly required to produce or release the product.

    Use in manufacturing workflows

    In integrated manufacturing environments, BOMs are used to:

    – Drive **material requirements planning** (MRP) and procurement in ERP systems
    – Define expected material consumption for **costing** and financial tracking
    – Inform **MES** or other shop-floor systems of required components for an order or batch
    – Support **traceability** by providing the expected structure against which actual material lots or serials are recorded

    During production, the BOM is typically linked to:

    – A **routing** or process definition (how work is done)
    – **Work orders**, production orders, or batch records (what is executed and when)
    – **Material master** data for each item listed

    Site context: BOM in MES–ERP integration and costing

    For program or product cost tracking across MES and ERP, the BOM commonly:

    – Resides and is maintained in ERP or PLM as the **authoritative product structure**
    – Provides the expected component list and standard quantities used to calculate standard or planned costs
    – Acts as the reference against which MES reports **summarized actual consumption** (by material ID and quantity) back to ERP at defined intervals

    In this context, MES usually does not author the BOM but uses it to validate material usage and ensure that recorded consumption aligns with the qualified product definition.

    Boundaries and exclusions

    A bill of materials **includes**:

    – Physical components, raw materials, and subassemblies
    – Sometimes non-stock items when they are integral to product composition (e.g., labels, certain consumables)

    A bill of materials **does not inherently include**:

    – Detailed work instructions, sequence of operations, or cycle times (these belong to routings or manufacturing instructions)
    – Real-time production data or yield results
    – Quality tests and acceptance criteria (these are typically defined in specifications or control plans)

    Some organizations maintain separate BOM types, such as **engineering BOM (EBOM)** and **manufacturing BOM (MBOM)**, to distinguish design intent from the structure used for actual manufacturing and sourcing.

    Common confusion and related terms

    – **BOM vs. recipe/formula**: In process industries, a *recipe* or *formula* includes process parameters and instructions in addition to material quantities. The BOM portion is the structured list of materials and quantities.
    – **BOM vs. routing**: A BOM defines *what materials* are required; a routing defines *how and in what sequence* operations are performed.
    – **BOM vs. product specification**: Specifications describe properties and performance requirements; the BOM lists the materials that make up the product.

    Understanding these distinctions helps ensure that BOMs are used consistently for planning, costing, and execution across ERP, MES, and quality systems.

  • Security documentation

    Security documentation is the structured set of written records that describe how an organization defines, implements, maintains, and verifies security controls for its systems, data, and operations. In industrial and manufacturing environments, it commonly covers both IT and OT assets, including production networks, MES, PLCs, SCADA, and related business systems.

    What security documentation includes

    Security documentation typically includes:

    • Policies that state high-level security expectations and responsibilities, such as acceptable use, access control, and incident response.
    • Standards and baselines that specify required configurations or control levels for systems, networks, and applications.
    • Procedures and work instructions that define step-by-step methods for implementing and operating security controls, such as user provisioning, patch deployment, or backup routines.
    • Architectures and diagrams that describe network zoning, data flows, trust boundaries, and system interfaces across IT and OT.
    • Risk and assessment records, including vulnerability assessments, threat models, and risk registers related to production systems.
    • Incident and change records that document security events, investigations, corrective actions, and security-relevant changes to systems.
    • Training and awareness records that show how personnel are informed about security expectations and procedures.
    • Access, configuration, and audit logs that provide evidence of how controls are used and monitored in daily operations.

    In regulated manufacturing, security documentation is often integrated with broader document control and quality management systems so that versions, approvals, and retention are managed consistently.

    Operational role in industrial environments

    In operations and manufacturing systems, security documentation commonly supports:

    • Design and engineering of secure OT and IT architectures for plants, lines, and equipment.
    • Commissioning and change management by defining how new equipment, MES integrations, and control system modifications are evaluated and documented from a security perspective.
    • Routine operations through documented procedures for account management, remote access, firmware and patch handling, and removable media usage on the shop floor.
    • Audit readiness by providing traceable evidence that security controls are defined, implemented, and periodically reviewed.
    • Incident handling via documented response plans, escalation paths, communication templates, and post-incident review forms.

    What security documentation is not

    Security documentation is not the security controls themselves. It does not guarantee that systems are secure or compliant, but instead describes:

    • What controls should exist and how they should work.
    • Who is responsible for implementing and operating them.
    • How activities and results are recorded and reviewed.

    It also differs from general IT or engineering documentation by focusing specifically on confidentiality, integrity, and availability concerns, as well as regulatory and contractual security requirements that affect manufacturing operations.

    Common confusion

    • Security documentation vs. cybersecurity program: The program is the overall set of activities and governance for security. Security documentation is the recorded description and evidence of that program.
    • Security documentation vs. safety documentation: Safety documentation addresses risks to people and equipment (for example, machine guarding and lockout/tagout). Security documentation addresses protection of systems and data from unauthorized access, change, or disruption, though both may reference the same assets in industrial settings.
    • Security documentation vs. system manuals: Vendor system manuals describe how to operate a product. Security documentation records how that product is configured and controlled within the organization’s specific security framework.

    Relation to compliance and audits

    In regulated or audited manufacturing environments, security documentation commonly serves as:

    • Evidence that security responsibilities, processes, and technical measures are defined and communicated.
    • Reference material for auditors and internal reviewers to understand how security is integrated with MES, ERP, and plant systems.
    • Supporting records for change control, deviation handling, and corrective or preventive actions with a security component.

    Organizations often align security documentation with recognized frameworks or standards while maintaining it under formal document control to keep records current and traceable.