A control objective is a clear, specific statement of what a control is supposed to achieve, the risk it’s meant to reduce or the outcome it’s meant to protect.
It matters because a control without a stated objective is just an activity with no way to judge whether it’s actually working. In practice, an organization looks at what could go wrong, decides how much risk it’s willing to accept, and writes an objective that describes the protected outcome, not the specific method.
For example, “all customer transactions must maintain a complete audit trail” is a control objective; the specific software or approval process used to achieve it is the control activity. In a Six Sigma project, this same idea appears in the Control Plan, where the control objective is almost always to sustain the process improvement achieved during the Improve phase.
Quick Reference Table
| Term | What It Means | Example |
| Control Objective | The specific goal or protected outcome a control is meant to achieve | “All journal entries must be reviewed and authorized before posting” |
| Control Activity | The specific action, policy, or procedure used to meet the objective | A manager’s digital sign-off required before a journal entry posts |
| Control | The general term for any policy, procedure, or check that manages risk | The overall review-and-approval system |
| KPI (Key Performance Indicator) | A measurable metric tracking whether an objective is being met | Percentage of journal entries reviewed within 24 hours |
| Six Sigma Control Plan | The DMAIC deliverable that documents how an improvement will be sustained | A plan specifying control charts, checks, and response actions after project close |
Table of contents
Key Takeaways
- A control objective describes an outcome, not a method. It states what result matters (“data must remain confidential”), not the specific tool or procedure used to get there.
- Control objectives come from risk assessment. An organization identifies what could go wrong, decides its risk tolerance, and writes objectives that address that risk directly.
- A control objective is different from a control activity. The objective is the goal; the activity is the specific action taken to meet it. One objective can be supported by several different activities.
- Frameworks like COBIT and COSO are built around control objectives. These frameworks organize IT governance and financial internal controls specifically around stated objectives rather than prescribed procedures.
- In a Six Sigma project, the control objective almost always means sustaining an improvement. The Control Plan built at the end of DMAIC exists specifically to keep a process from sliding back to its pre-improvement state.
- A good control objective is specific and measurable, but not overly prescriptive. It should be precise enough to check whether it’s being met, while leaving room for different valid ways to meet it.
- Control objectives connect daily work to strategic priorities. They give a team a reason “why” a specific check or procedure exists, not just an instruction to follow it.
What Is a Control Objective?
A control objective is a clearly defined statement of what a control is designed to accomplish. It describes the protective result that matters, preventing fraud, maintaining accuracy, protecting data, sustaining a process improvement, rather than specifying exactly how that result should be achieved.
Control objectives typically come out of a risk assessment process. An organization looks at what could realistically go wrong, decides how much of that risk it’s willing to accept, and then writes an objective describing the outcome it needs to protect against that risk.
A financial services firm might set an objective that every transaction must maintain a complete audit trail for a set number of years, or that customer authentication must resist common attack methods. The objective itself doesn’t name a specific technology or procedure; it states the result that has to hold true no matter which method is used to get there.
Public, Onsite, Virtual, and Online Six Sigma Certification Training!
- We are accredited by the IASSC.
- Live Public Training at 52 Sites.
- Live Virtual Training.
- Onsite Training (at your organization).
- Interactive Online (self-paced) training,
Why Do Control Objectives Matter?
Control objectives matter because they give a control a reason to exist, and a way to check whether it’s actually working. Without a stated objective, a control is just an activity someone performs, with no clear standard for judging whether that activity is accomplishing anything real.
Good control objectives connect the daily, tactical work, filling out a form, reviewing a log, running a check, to the strategic reason that work matters. This connection is what lets a team understand why a specific control exists, rather than treating it as an arbitrary box to check. It also gives leadership a way to evaluate whether the control environment as a whole is actually protecting the organization, rather than just generating paperwork.
Also Read: Micromachining: What It Is, How It Works, and Why Quality Control Matters
Control Objective vs. Control Activity vs. Control: How Do They Compare?
This is the distinction most business searchers actually need, and it’s often blurred together in casual use.
| Term | Answers the Question | Example |
| Control Objective | “What outcome are we protecting?” | Financial records must be accurate and complete |
| Control Activity | “What specific action achieves that?” | A two-person review and sign-off before entries post |
| Control | “What’s the general mechanism?” | The overall review-and-approval process, as a whole system |
| Business Objective | “What is the organization trying to achieve overall?” | Maintain investor and regulator trust in financial reporting |
How do these connect in practice?
A business objective (maintain financial trust) leads to a control objective (ensure all entries are accurate and authorized), which is achieved through one or more control activities (a specific review-and-sign-off procedure), all of which together form part of the organization’s broader control environment.
Understanding this chain matters because it clarifies that a single control objective can be met through more than one control activity, and that changing the activity doesn’t require changing the objective, as long as the same outcome is still protected.
Control Objective vs. KPI: How Do They Compare?
A control objective states the goal; a KPI (Key Performance Indicator) measures whether that goal is actually being met on an ongoing basis.
| Factor | Control Objective | KPI |
| What it is | A stated goal or protected outcome | A measurable metric tracking performance against a goal |
| Format | A descriptive statement | A number, percentage, or rate |
| Example | “All journal entries must be reviewed and authorized” | “98% of journal entries reviewed within 24 hours” |
| Changes how often? | Rarely, tied to ongoing risk | Regularly, tracked and reported on a set cadence |
A control objective without a supporting KPI is difficult to monitor in practice; a KPI without a stated control objective behind it risks measuring something that doesn’t actually connect to a real risk or strategic priority.
Also Read: Six Sigma in Food and Beverage Manufacturing: Control Yield & Quality
Where Do Control Objectives Come From?
Control objectives gained formal structure through the evolution of corporate governance and financial auditing. The Committee of Sponsoring Organizations (COSO) formalized control objectives in its 1992 Internal Control framework, establishing principles that extended from finance into broader operational and compliance domains.
As computing became central to business operations, IT-specific frameworks adopted the same thinking. COBIT (Control Objectives for Information and Related Technologies), first published in 1996, adapted control objective thinking specifically for IT governance, and remains one of the most widely referenced frameworks organized around this concept today.
ISO 27001, the international information security standard, similarly structures much of its guidance around defined control objectives rather than prescribed technical procedures.
What Are the Common Types of Control Objectives?
Control objectives are typically grouped by the type of risk they address:
- Accuracy objectives — ensuring records and data are complete and free from errors.
- Authorization objectives — ensuring transactions or changes are approved by the right person before they take effect.
- Confidentiality objectives — protecting sensitive data from unauthorized access.
- Compliance objectives — ensuring processes meet relevant legal or regulatory requirements.
- Operational reliability objectives — ensuring a process or system performs consistently and predictably.
How Do You Write a Good Control Objective?
1. Start From an Identified Risk
A control objective should trace back to a specific, identified risk. Without a clear risk behind it, an objective tends to be vague or arbitrary.
2. Describe the Outcome, Not the Method
Write the objective around the protected result (“customer data remains confidential”), not the specific tool or procedure (“we use encryption software X”). This keeps the objective valid even if the underlying method changes later.
3. Make It Specific Enough to Measure
A good control objective should be precise enough that someone could reasonably check whether it’s being met, ideally by attaching a KPI to it, without being so narrow that it locks in one single implementation.
4. Confirm It Connects to a Real Priority
Check that the objective ties back to an actual business, compliance, or quality priority. An objective that doesn’t connect to something the organization genuinely cares about tends to get ignored in practice.
How Does a Control Objective Fit Into a Six Sigma Control Plan?
This is the connection no competing source currently makes, and it’s the most directly useful application for SSDSI’s audience.
At the end of a DMAIC project, the team builds a Control Plan, a document specifying how the process improvement achieved during the Improve phase will actually be sustained going forward. The Control Plan’s core control objective is almost always some version of the same idea: keep the improved process from drifting back to its old, worse-performing state.
That general objective breaks down into more specific ones depending on what was actually improved:
- If the project reduced defects, the control objective might be stated as “maintain the defect rate below X per million opportunities.”
- If the project reduced cycle time, the objective might be “maintain average cycle time at or below Y minutes.”
- If the project addressed a safety issue, the objective might be “maintain zero incidents of the identified failure mode.”
The control activities that support this objective are the specific tools in the Control Plan: control charts, standard operating procedures, training requirements, and defined response plans for when a metric moves outside its expected range. Just as in the general governance context, the objective states the protected outcome; the control chart, the SOP, and the response plan are the specific activities used to achieve it.
Real-World Example (Hypothetical)
Problem: A manufacturing team has just completed a DMAIC project reducing a specific weld defect from 4% to 0.5%. Without a clear plan, this kind of gain often erodes within a few months as operators drift back to old habits.
Analysis: The team recognizes that “don’t let the defect rate creep back up” is too vague to actually manage. It needs a specific, measurable control objective.
Six Sigma approach: The Control Plan states the control objective directly: “Maintain weld defect rate at or below 0.5% on a rolling 30-day basis.” This is supported by two control activities: a control chart tracking daily defect rate, and a standard operating procedure requiring a supervisor check if any single day exceeds 1.5%.
Action: Three months after project close, the control chart shows a slow upward trend approaching the 1.5% trigger. The supervisor check catches the drift and traces it to a new batch of welding wire.
Result (hypothetical): The defect rate is corrected before it fully erodes the original improvement, because the control objective was specific enough to build a real trigger point around. This is a hypothetical illustration of a control objective in practice, not a documented case study.
Common Mistakes When Setting Control Objectives
- Writing the objective as a method instead of an outcome. “Use software X to review entries” describes an activity, not an objective; the actual objective is the outcome that review is meant to protect.
- Making the objective too vague to measure. “Improve quality” isn’t a control objective; “maintain defect rate below X” is.
- Setting a control objective with no supporting KPI. Without a metric attached, there’s no practical way to know whether the objective is actually being met.
- Confusing a control objective with a business objective. A business objective is the broad organizational goal; a control objective is the specific, narrower outcome a particular control protects, in service of that broader goal.
- Failing to connect a Six Sigma Control Plan’s objective to a specific, measurable target. A Control Plan that only says “sustain the improvement” without a number attached gives the team nothing concrete to monitor against.
Frequently Asked Questions (FAQs) on Control Objective
Q: What is a control objective?
A: A control objective is a clearly defined statement of what a control is designed to achieve, the protected outcome or reduced risk it’s meant to deliver, rather than the specific method used to get there.
Q: What is an example of a control objective?
A: “All customer transactions must maintain a complete audit trail” or “customer authentication must resist common attack methods” are both control objectives. In a Six Sigma context, “maintain defect rate below 0.5% on a rolling 30-day basis” is a control objective for a Control Plan.
Q: What is the difference between a control objective and a control activity?
A: The control objective is the goal or protected outcome. The control activity is the specific action, policy, or procedure used to achieve that goal. One control objective can be supported by more than one control activity.
Q: How do control objectives relate to COBIT and COSO?
A: COSO formalized control objectives for financial internal controls starting in 1992, and COBIT later adapted the same concept specifically for IT governance, starting in 1996. Both frameworks organize their guidance around stated control objectives rather than prescribed procedures.
Q: How does a control objective fit into a Six Sigma Control Plan?
A: The Control Plan built at the end of a DMAIC project has its own control objective, almost always some version of sustaining the improvement achieved during the Improve phase, expressed as a specific, measurable target the team monitors going forward.
Q: How do you write a good control objective?
A: Start from an identified risk, describe the protected outcome rather than the specific method, make it precise enough to measure (ideally with a supporting KPI), and confirm it connects to a real business or quality priority.
Final Words
A control objective is what turns a control from an arbitrary activity into something with a defined purpose you can actually check. Whether it’s an IT governance framework like COBIT protecting data confidentiality, or a Six Sigma Control Plan protecting a hard-won process improvement, the underlying logic is the same: state the outcome you need to protect, then build the specific activities that deliver it.
Getting that objective specific and measurable, rather than vague, is what keeps a control from becoming paperwork nobody checks.
Writing a Control Plan with a clear, measurable control objective is what actually protects a Six Sigma project’s results after the team moves on to the next initiative.
Six Sigma Development Solutions, Inc. (SSDSI) is IASSC-accredited and 5-star rated on Google Reviews, having certified 5,322+ professionals across 600+ organizations in 52 cities. Our onsite, live virtual, public, and online Green Belt and Black Belt training covers Control Plans, control charts, and sustaining process improvements in the depth needed to make your gains stick. Explore SSDSI’s Black Belt certification to build that capability.
About Six Sigma Development Solutions, Inc.
Six Sigma Development Solutions, Inc. offers onsite, public, and virtual Lean Six Sigma certification training. We are an Accredited Training Organization by the IASSC (International Association of Six Sigma Certification). We offer Lean Six Sigma Green Belt, Black Belt, and Yellow Belt, as well as LEAN certifications.
Book a Call and Let us know how we can help meet your training needs.
