Quality Assurance vs Quality Control: Key Differences

Ask ten quality people for the difference and nine give the same sentence: QA prevents defects, QC detects them. It's correct. It's also close to useless the moment somebody hands you a real activity and asks which bucket it goes in.

Is a first-article inspection quality control? Probably. Is the decision that one is required at all quality assurance? Yes. Is the supplier audit verifying your vendor runs those inspections quality assurance, even though the auditor spends the day reading inspection records? Also yes. Same measurements, three answers, and the prevention-versus-detection line explains none of them.

So this page starts somewhere firmer, with the definitions in ISO 9000:2015, then does the work the one-liner skips: which activities belong to which, who owns each, where both land in a management system, what the split looks like in software and services, and which of the two is failing you when the same defects keep coming back.

Key Facts: QA and QC

• ISO 9000:2015 defines quality assurance as "part of quality management focused on providing confidence that quality requirements will be fulfilled" and quality control as "part of quality management focused on fulfilling quality requirements" (ASQ).
• They aren't peers: "QA activities and responsibilities cover virtually all of the quality system in one fashion or another, while QC is a subset of the QA activities" (ASQ).
• Before Google's web server team required tests with every change, "more than 80% of production pushes contained user-affecting bugs that had to be rolled back"; within a year, emergency pushes dropped by half (Software Engineering at Google).
• ISO 9001:2015 is the edition in force as this is written; the sixth edition is scheduled for publication on 16 September 2026 (ISO/TC 176/SC 2).

What the Standard Actually Says

ISO 9000:2015 is the fundamentals and vocabulary standard underneath ISO 9001. It defines both terms in one breath, deliberately parallel.

Both pairs come from ASQ's reference page, which credits ISO 9000:2015.

Side by side, the distinction turns on one word: confidence. Quality control points at the requirement itself, fulfilling it. Quality assurance points at somebody's belief about the requirement, and that belief has to be demonstrable, which is why so much of QA turns out to be planning, documentation and audit rather than measurement.

Notice what the definitions refuse to say. Neither mentions timing, and neither says "before production" or "after production". Both open with the same four words, "part of quality management," so neither is the whole job. They aren't equal halves facing each other; one sits inside the other. The asymmetry matches the history, which ASQ dates to the 1920s for quality control, when mass manufacturing needed a way to manage product variation, and the 1950s for quality assurance and formal auditing, where public health and safety were at stake and somebody outside the factory needed a reason to believe it.

Where this page draws its line

This library already carries a sector deep dive on the same pair: Quality Control vs Quality Assurance, in the manufacturing collection. That's the right page if you run a plant. It goes deep on detection mechanisms (100% inspection versus sampling, first-piece and patrol inspection), measurement systems, nonconforming material handling, shop-floor reporting lines, and how the balance shifts across automotive, aerospace and medical devices.

This page stays out of the plant. It's the definitional reference: what the standards say, a sorting rule for which activity is which, who owns each, where both land in a clause structure, the neighbouring terms people collide with, and the same split in software and services. Want depth on inspection method? Follow the link above. Want to settle an argument about what counts as which? Stay here.

Why "QA Prevents, QC Detects" Is True and Almost Useless

The one-liner is a fair summary of intent. It fails as a sorting rule, for three reasons.

Most useful activities do both. A control chart flags a point outside the limits, which is textbook detection. But you plot one to catch drift while the parts are still good, which is prevention. Detection performed early enough is prevention, so a rule built on that split cuts the activity in half.

The same artefact changes bucket depending on who's holding it. An inspection record is QC output when the inspector writes it. It's QA evidence when an auditor samples twenty of them next quarter to check the control plan was followed. Nothing about the document changed. The purpose did.

Prevention and detection describe timing, and the standards deliberately don't. ISO 9000 splits on confidence, not on when the clock strikes. That's what lets one definition cover a stamping press, a deployment pipeline and a claims team, where "before production" means nothing comparable.

A better test is two questions, in order:

1. Does this decide the fate of a specific unit, batch, release or transaction that exists right now? If yes, it's quality control. Accept, reject, rework, scrap, ship, roll back.
2. Does this change the probability that future outputs conform, or produce demonstrable evidence that they will? If yes, it's quality assurance.

Plenty of activities answer yes twice, which isn't a flaw in the test. It means you're looking at a QC activity operating inside a QA system, exactly what ASQ means by calling QC a subset. The question worth arguing is never "is this QA or QC" in the abstract. It's "which of those jobs is this doing for us, and is anybody doing the other one?"

A Sorting Rule for Real Activities

Here's that test applied to the activities that generate the most argument.

Calibration is the row worth pausing on. Calibrating a caliper prevents no defect, so it feels like a support task. But if the gauge drifts, your whole detection layer starts lying to you and every accept decision becomes suspect. Calibration is assurance about your control system, QA in the purest sense of the ISO wording.

Who Owns What

The definitions don't assign owners. Organizations do, and getting that wrong is more common than getting the definitions wrong. This pattern holds across sectors even when titles vary.

Independence is the thread running through that table, and it's why audit is structured as it is. ASQ classifies audits by who performs them: first-party is internal, run against an organization's own procedures; second-party is performed on a supplier by the customer buying from it; third-party comes from an independent body with no supplier-customer stake, and is what produces a certificate (ASQ). That's a confidence ladder: the further from the work the auditor stands, the more the evidence is worth outside the company.

One structural rule survives every context: QC must not report to the person whose output it's judging.

Where QA and QC Sit in a Quality Management System

ISO 9001:2015 organizes its requirements into clauses 4 through 10. Mapping QA and QC onto them beats the abstract definitions, because it shows how lopsided the split really is.

Clause descriptions follow ASQ's summary of the standard. Sub-clause numbering shifts between editions, so anchor arguments on the clause, not the decimal.

Two things fall out. Six of the seven clauses are pure assurance, with quality control compressed almost entirely into clause 8, so a quality function staffed mostly with inspectors is staffed against a seventh of the standard. And clauses 9 and 10 exist to consume what QC produces, so they have nothing to work with if inspection data never leaves the shop floor. The standard assumes a loop, and the loop is the part organizations skip. The same skeleton runs through other ISO management-system standards, which is why a manager working to ISO 14001 recognizes the shape instantly.

A timing note, since this page will outlive the news cycle. ISO 9001:2015 is the edition in force as this is written, and the sixth edition is scheduled for publication on 16 September 2026 after an approved final draft ballot (ISO/TC 176/SC 2). Certified organizations then get a transition window, typically two to three years, though certification bodies caution it may run shorter (DNV). None of that touches the definitions, which live in ISO 9000.

The Neighbouring Terms People Confuse With Both

Half the confusion here isn't QA versus QC. It's one of these six terms wearing the wrong label.

Two deserve another sentence. Inspection and audit look alike and aren't: both examine evidence against a requirement, but an inspection judges an output and an audit judges a system, which is why they produce different artefacts, a disposition versus a finding. And quality improvement is not QA. Assurance holds a standard; improvement moves it. A process running at target with stable output has excellent assurance and zero improvement happening, which is a legitimate state to be in. Conflating the two is how improvement projects get defunded the moment the audit passes.

The Same Split in Software

Software inherited this vocabulary and bent it. In most engineering organizations, "QA" names the team that runs tests, which is precisely quality control by the ISO definition. Ignore the org chart and sort the work.

The clearest illustration lives in Google's own engineering handbook. By 2005 its web server team had reached a state where "more than 80% of production pushes contained user-affecting bugs that had to be rolled back." The response wasn't more testers. It was a rule: all new code changes had to include tests, run continuously. "Within a year of instituting this policy, the number of emergency pushes dropped by half," while the team kept setting records for change volume (Software Engineering at Google, ch. 11).

Look at the shape of that. The tests are quality control, each passing or failing a build. The policy that every future change must carry them is quality assurance: a systematic activity providing demonstrable confidence about output nobody has written yet. Teams chasing the same result with more manual testing are buying more QC, and the arithmetic fails, because inspection capacity scales with change volume and a policy doesn't.

The Same Split in a Service Business

Services are where people assume quality control stops applying, on the grounds that there's no unit to inspect. ASQ's answer is that a service organization with no tangible product still applies QC to the documents and materials supporting delivery.

A service commitment makes it cleaner. The AWS Compute SLA, effective 25 May 2022, commits to 99.99% monthly uptime at the region level for EC2 and 99.5% at the instance level, with a fixed remedy when it misses:

Three jobs are visible in that one document. Writing the number, and deciding the architecture can hold it, is quality planning. Measuring last month's uptime and issuing a credit when it missed is quality control: a pass-or-fail judgment on a period that already happened. Capacity planning, change management, failure testing and runbooks are quality assurance, because they make 99.99% likely rather than lucky. Our SLA examples and templates page covers the commitment itself.

The same roles show up everywhere in services. Scoring a sampled call is QC; the coaching program and call-flow redesign built on those scores are QA. A four-eyes check on an invoice is QC; the approval matrix deciding which invoices need four eyes is QA. A partner reviewing a deliverable is QC; the template and peer-review requirement are QA. The pattern matches the factory exactly: a judgment on one instance, inside a system designed to make good instances the default.

The Honest Version of the Cost Argument

The standard case for moving effort from QC to QA is that prevention beats detection, and detection beats failure. The version usually quoted is the 1-10-100 rule: a dollar to prevent a defect, ten to fix it internally, a hundred once the customer has it. Treat that as a principle, not a measurement, because it's a memorable ordering of cost categories rather than a finding you can look up.

What is genuinely structured is the category model. Quality cost splits four ways: prevention, appraisal, internal failure and external failure (ASQ). QA spending is prevention, QC spending is appraisal, defects your controls catch are internal failure, and defects your customer catches are external failure. Our cost of quality page works through the arithmetic.

Now the uncomfortable part: most organizations can't run the argument, because they don't have the numbers. In the 2025 ASQE Insights on Excellence Cost of Quality Report, only 31% of respondents said they fully understand how quality costs affect their organization's financial performance (ASQ). The pitch to shift budget from inspection to prevention is usually made on conviction, which is better admitted than dressed up.

Two things hold up without a model. Appraisal never reaches 100%: inspection has an escape rate, sampling carries consumer's risk, test suites have gaps. Adding inspectors moves that rate; it doesn't zero it. Prevention is the only lever that shrinks the population of defects rather than the fraction getting through. And the later you catch it, the more it costs. Google's handbook puts it directly: "The later in the development cycle a bug is caught, the more expensive it is; exponentially so in many cases" (Software Engineering at Google). You don't need a coefficient to act on a direction.

For one metric that makes the shift visible, use first pass yield: units through the whole process right the first time, no rework. Rising FPY at flat inspection spend is QA working. Flat FPY at climbing inspection spend is the opposite, and it's measurable this quarter.

The Failure Mode: Documents, Inspection, and No Loop Between Them

One broken configuration shows up more than any other, and its defining feature is that it passes audits. The symptoms look like health: procedures exist, the document register is current, the audit schedule is met, corrective actions close on time, and inspection is fully staffed and reliably finding defects. And this quarter's defect Pareto is a near copy of the one from four quarters ago.

What's missing isn't QA and it isn't QC. It's the arrow between them. Inspection data is sorting product, not changing process. Nonconformance reports get raised, dispositioned and closed one at a time, and nobody aggregates them. Audit findings go to a file rather than the person who owns the failing process.

Three questions diagnose it faster than an audit:

1. When did a control plan, SOP or test policy last change because of something inspection found?
2. Can the quality manager name last quarter's top three defect modes without opening a system?
3. Does a repeat nonconformance trigger anything different from a first-time one?

Toyota's production system is the reference implementation of the loop working, and it's deliberately physical. When equipment detects an abnormality it stops itself, and "the andon (problem display board) lights up to notify workers of the abnormality"; a worker spotting a problem can pull the stop cord to bring a supervisor (Toyota). Toyota calls the principle jidoka, "automation with a human touch." The detection is quality control. The stop, and the expectation that the cause gets removed rather than the part sorted out, convert it into assurance.

Rebuilding the loop is unglamorous and mostly procedural. Hold a standing defect review over aggregated data, not individual reports. Gate corrective-action closure on verified root cause rather than containment, which is where root cause analysis earns its keep. Treat the control plan as a living document with an owner, and route audit findings to process owners with a due date. Use the seven quality tools to turn nonconformance records into something a team can read. A total quality management posture is this loop made everybody's job.

Which One Is Failing You Right Now

Most teams asking "QA or QC?" are asking a diagnostic question in disguise. This table answers that version.

The pattern in every row is the same. Quality control tells you what happened. Quality assurance decides what happens next. When people argue about the definitions, they're usually arguing about which of those jobs their organization quietly stopped doing, and the argument gets shorter once somebody names it.