Release of products and services

“Release of products and services” is where your quality management system becomes real. Clause 8.6 is not asking for more testing in the abstract; it is asking for disciplined, planned arrangements that prove requirements were met before you release a deliverable to a customer or into production. That includes physical shipments, software deployments, professional services deliverables, and any outsourced work you resell or integrate.

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize this requirement is to treat release as a controlled decision: (1) define what must be true before release, (2) define who can approve release, (3) capture objective evidence that requirements are met, and (4) prevent bypass unless a relevant authority (or the customer) explicitly approves an exception. Most audit findings happen because teams “do the work” but cannot prove they followed planned release arrangements consistently, or because release happens informally (email, chat, tribal knowledge) without durable records.

This page translates Clause 8.6 into a practical release-control playbook, with steps, artifacts, audit-ready evidence, and common failure modes.

Regulatory text

ISO 9001:2015 Clause 8.6 states: “The organization shall implement planned arrangements to verify that product and service requirements have been met.” ¹

Operator interpretation (what you must do):

• You must plan how you will verify requirements (not improvise per project).
• You must verify product/service requirements are met before release (shipment, go-live, handoff, or customer acceptance).
• You must record evidence of verification and the release decision, including who approved it.
• You must control release exceptions (e.g., open nonconformities, waived requirements) and ensure an appropriate authority or the customer approves the exception, with records retained. This expectation is reflected in common interpretations of Clause 8.6’s “release shall not proceed until satisfactorily completed unless approved by a relevant authority or customer” summary. ¹

Plain-English requirement

Before you deliver anything to a customer (or put it into production), you need a defined release process that checks the deliverable against its requirements and produces a record showing the checks passed (or were properly waived), and that an authorized person approved the release.

Who it applies to

Entities: Any organization operating an ISO 9001 quality management system. ¹

Operational contexts where Clause 8.6 becomes “real”:

• Manufacturing / distribution: final inspection, test results, COA/COC, labeling verification, shipping authorization.
• Software / SaaS: build promotion to production, feature flags enabling customer access, app store releases, API version releases, security hotfix releases.
• Professional services: deliverable acceptance (reports, configurations), handover checklists, customer sign-off, completion criteria.
• Third-party supported delivery: outsourced manufacturing, subcontracted services, cloud-hosted components where the third party’s output becomes part of your deliverable.

If you have multiple release points (e.g., internal QA sign-off, staging approval, production deployment, customer acceptance), treat each as a planned release stage with defined criteria.

What you actually need to do (step-by-step)

1) Define what “release” means in your business

Create a short list of release events that trigger Clause 8.6 controls, for example:

• Ship physical product
• Make a service deliverable available to the customer
• Deploy to production or enable a feature for customers
• Transfer custody (handoff) or declare completion

Practical tip: Write this as a one-page “Release Scope Statement” and keep it aligned with your order-to-cash and change/release processes.

2) Define release criteria tied to requirements

For each product/service family, define release criteria that map to:

• Contract/customer requirements (specs, SLAs, acceptance criteria)
• Regulatory or statutory requirements (if applicable to the product/service)
• Internal requirements (work instructions, design outputs, quality plans)

Outputs:

• A Release Checklist (or equivalent) that references the requirement source and the evidence type required (test result, inspection record, peer review, customer acceptance email).

3) Plan verification activities and acceptance thresholds

Clause 8.6 expects “planned arrangements,” which should include:

• What verification is performed (inspection, test, review, reconciliation)
• When it is performed (stage gates)
• Who performs it (competence/role)
• What “pass” means (tolerances, acceptance criteria)
• What tools or methods are used (calibrated equipment, validated scripts, peer review standards)

For services, verification may look like:

• Checklist completion plus peer review
• Reconciliation to statement of work requirements
• Customer acceptance sign-off

4) Assign release authority and segregation of duties where it matters

Define who can approve release:

• Role-based approvers (Quality, Engineering, Service Delivery Manager)
• Delegation rules (who can act in absence)
• Independence rules where required by your risk profile (e.g., separate builder from releaser for production deploys)

Keep it simple: auditors look for clarity and consistency more than complex RACI diagrams.

5) Build an exception path (controlled release with open items)

You need a controlled mechanism for:

• Concessions/waivers (requirement not fully met)
• Deviations (temporary departures from spec)
• Known issues accepted for release (with mitigations)

Minimum controls:

• Document the nonconformity or deviation
• Record the risk decision and conditions (scope, time limit, affected customers)
• Record approval by the relevant authority and/or customer, as appropriate ¹. ¹

6) Record release evidence and keep it retrievable

You need durable, traceable records that connect:

• The specific product/service instance (batch/serial, order number, release ticket ID)
• The verification evidence
• The release approval (who/when)
• Any exceptions and their approvals

Daydream fit (natural operational resolution): If your evidence is scattered across email, chat, and CI/CD logs, you will spend audit week reconstructing history. A system like Daydream can centralize release records, link evidence to each release gate, and produce an audit-ready packet per release without manual chasing.

7) Monitor and improve release performance

Feed release outcomes into:

• Nonconformity and corrective action processes
• Complaint handling
• Management review inputs (trend themes, repeat escape points)

Auditors often test whether release failures trigger corrective action and process updates.

Required evidence and artifacts to retain

Keep records proportional to risk and complexity, but ensure you can show objective evidence for each release.

Core artifacts (typical):

• Release procedure / work instruction (controlled document)
• Release scope statement (what counts as release)
• Release criteria/checklists by product/service line
• Verification records (inspection/test results, peer review records, reconciliations)
• Release approval record (signature/e-signature, date/time, approver role)
• Exception/concession records with approval authority and any customer approval (when applicable)
• Traceability links (order → build/service work → verification → release)

Good audit posture: A single “release packet” per shipped item, deployment, or service deliverable.

Common exam/audit questions and hangups

Auditors tend to probe the same weak points:

1. “Show me the last release.”
   They will pick a recent shipped order, deployment, or deliverable and ask for the complete evidence trail.

2. “Where are the acceptance criteria defined?”
   If requirements live only in sales emails or tribal knowledge, you will struggle to show planned arrangements.

3. “Who can approve release, and how do you prevent bypass?”
   They look for role clarity plus system/process controls that stop informal release.

4. “How do you handle nonconforming outputs at release?”
   Expect a deep dive on waiver/concession controls and customer approvals where applicable.

5. “Is this consistent across teams?”
   A common hangup is one team doing disciplined releases while another does informal handoffs.

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating release as “QA did some testing”

Fix: Define the release decision and authority explicitly. Verification is necessary; approval and records complete the control.

Mistake 2: No clear mapping between requirements and checks

Fix: In the release checklist, include a column for requirement source (contract/SOW/spec) and the evidence type.

Mistake 3: Evidence exists but is not linked to the released item

Fix: Require an identifier (order number, batch, ticket) on every verification record and store it with the release approval.

Mistake 4: Exceptions are handled informally

Fix: Create a concession path with approval rules and required documentation. Make it easier than side-channel approvals.

Mistake 5: Third-party deliverables “inherit trust”

Fix: Treat third-party outputs as part of your release. Require incoming verification evidence, acceptance checks, or certificates as part of the release packet.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is operational and contractual: releasing without verified conformance drives customer complaints, rework, service credits, recalls, incident response, and audit nonconformities. Clause 8.6 findings often cascade into broader QMS concerns because weak release controls also imply weak traceability, weak corrective action triggers, and inconsistent execution.

Practical execution plan (30/60/90-day)

Timelines below are phased for execution clarity; adjust to your change calendar and audit schedule.

First 30 days (stabilize and define)

• Inventory release events across the business (products, services, software).
• Select one “reference process” to standardize from (often software release or final product shipment).
• Draft the release procedure: criteria, approvers, records, exception path.
• Define the minimum release packet content and storage location.

By 60 days (implement and prove)

• Roll out release checklists for each product/service family.
• Train approvers and implement sign-off capture (e-signature acceptable if controlled).
• Pilot the process on real releases, then correct friction points.
• Start capturing exceptions in a structured way (concession/waiver form or ticket type).

By 90 days (scale and harden)

• Expand to all teams and release types; eliminate shadow release paths.
• Add monitoring: periodic sampling of release packets for completeness.
• Connect release escapes to corrective action (update checklists, improve verification steps).
• Prepare an audit-ready demo: select recent releases and validate records are complete, traceable, and retrievable.

Frequently Asked Questions

What counts as “release” for a SaaS company?

Any action that makes functionality or a service outcome available to customers can be a release, including production deployments, enabling feature flags, and delivering customer reports. Define your release events explicitly so teams cannot bypass the gate.

Do we need a signature on every release?

You need a recorded approval by an authorized role for each defined release event, plus evidence that requirements were verified. That can be an electronic approval in a ticketing or QMS tool if it is controlled and traceable.

Can we release with open defects or incomplete requirements?

Clause 8.6 expectations allow release only after verification is satisfactorily completed unless a relevant authority or the customer approves an exception. Record the decision, conditions, and approval as part of the release packet. ¹

How do we handle third-party produced components?

Treat third-party outputs as inputs to your release gate. Require objective evidence (incoming inspection, certificate, acceptance test results) and link it to the specific batch/order you release.

What evidence is “objective” for service deliverables?

Objective evidence can include checklist completion with named reviewer, peer review notes, reconciliation to SOW acceptance criteria, and customer acceptance sign-off. The key is that the evidence ties to defined requirements and the specific deliverable.

Our teams already test and review—why do auditors still write findings?

Findings usually stem from weak records, unclear release authority, or inconsistent execution across teams. If you cannot produce a complete release packet quickly for a sampled release, auditors treat the control as ineffective.

Footnotes

1. ISO 9001:2015 Quality management systems — Requirements