Objective 1.3High Priority8 min read

Change Approval Process

Formal procedures for reviewing and approving changes to IT systems. Includes establishing change ownership, involving appropriate stakeholders, and following structured approval workflows to ensure changes are properly vetted before implementation.

Understanding Change Approval Process

The change approval process ensures that no change happens in isolation. Before any modification to IT systems, the right people must review it, understand its implications, and formally approve it. This prevents one person's decision from creating organization-wide problems.

Change approval involves three key elements: • Ownership — Someone is accountable for the change • Stakeholders — Affected parties have input and visibility • Approval — Formal authorization before implementation

Without proper approval processes, changes get made without considering impacts on security, business operations, or other systems. The approval process is the checkpoint that catches problems before they become incidents.

Why This Matters for the Exam

SY0-701 specifically tests change ownership and stakeholder involvement. Questions may present scenarios asking who should approve a change, who needs to be involved, or what happens when approval processes are bypassed.

Understanding approval workflows also helps with compliance questions. Auditors want to see documented approval for every change—who requested it, who approved it, and why. Organizations that can't demonstrate proper approval often fail compliance audits.

The approval process is also a security control itself. By requiring multiple parties to review changes, it prevents both malicious insiders and well-meaning but dangerous modifications.

Deep Dive

Change Ownership

Every change needs an owner who is accountable for: • Submitting the change request with complete information • Ensuring proper testing is performed • Coordinating with stakeholders • Overseeing implementation • Taking responsibility for outcomes

Owner Responsibilities:

  • Define the change scope and objectives
  • Identify affected systems and stakeholders
  • Provide business justification
  • Ensure resources are available
  • Accept accountability for results

Without clear ownership:

  • No one is accountable when things go wrong
  • Changes fall through the cracks
  • Follow-up and verification don't happen

Stakeholder Involvement

Stakeholders are people or groups affected by or interested in the change.

Types of Stakeholders:

StakeholderInterestInput Needed
Business ownersService availabilityBusiness impact, timing
Security teamSecurity implicationsRisk assessment
OperationsImplementationTechnical feasibility
End usersFunctionalityUsability concerns
ComplianceRegulatoryAudit requirements
ManagementResources, riskApproval authority

Why Stakeholder Involvement Matters:

  • Different perspectives catch different problems
  • Affected parties can prepare for the change
  • Reduces resistance and surprises
  • Ensures business needs are considered
  • Improves change success rate

The Change Advisory Board (CAB)

The CAB is the governance body that reviews and approves changes.

CAB Composition:

  • Change manager (facilitates meetings)
  • IT representatives (technical expertise)
  • Security representative (security review)
  • Business representatives (business impact)
  • Operations (implementation perspective)

CAB Responsibilities:

  • Review change requests
  • Assess risk and impact
  • Approve, reject, or defer changes
  • Prioritize competing changes
  • Review emergency changes retroactively

CAB Meeting Cadence:

  • Regular meetings (weekly/biweekly) for normal changes
  • Emergency CAB for urgent changes
  • Post-implementation reviews

Approval Workflows

Standard Change Approval:

  • Pre-approved changes that follow documented procedures. Examples: password resets, adding standard users.
  • No CAB review required
  • Must match pre-approved criteria exactly
  • Still logged and documented

Normal Change Approval:

  • 1.Change request submitted
  • 2.Initial review by change manager
  • 3.Stakeholder review and input
  • 4.CAB review and discussion
  • 5.Approval, rejection, or deferral
  • 6.Implementation scheduling

Emergency Change Approval:

  • 1.Verbal approval from designated authority
  • 2.Immediate implementation
  • 3.Documentation completed after
  • 4.CAB retroactive review
  • 5.Lessons learned captured

Approval Levels

Change RiskApproval Required
Low risk (standard)Pre-approved or manager
Medium riskCAB approval
High riskCAB + executive approval
EmergencyDesignated authority + retroactive CAB

How CompTIA Tests This

Example Analysis

Scenario: A database administrator wants to apply a schema change that will affect how the billing application stores customer data. The change will require a brief outage. Who should be involved in approving this change?

Analysis: Multiple stakeholders need involvement: • Database owner — Accountable for the change • Billing application team — Their application is affected • Business/Finance — Customer data and billing are impacted • Security team — Customer data handling changes • Operations — Implementation and outage management • CAB — Formal approval authority

Key insight: The database admin shouldn't just make this change because they have technical access. The change affects multiple systems and stakeholders who need to review, prepare, and approve.

What would go wrong without proper approval: • Billing application might break due to schema changes • Customer data handling might violate compliance requirements • Outage might occur during peak billing period • No one prepared for the change or its consequences

Key Terms to Know

change approvalchange advisory boardCABstakeholderschange ownershipapproval workflowchange control

Common Mistakes to Avoid

Thinking the person implementing the change should also approve it—separation of duties requires different people to request, approve, and implement changes.
Only involving technical stakeholders—business owners, compliance, and end users often have critical input that technical teams miss.
Treating CAB as a rubber stamp—the CAB should genuinely review changes, not just approve everything submitted.
Skipping approval for "minor" changes—even small changes can have unexpected impacts. The approval process should scale with risk, not be skipped entirely.

Exam Tips

Change ownership = Accountability. The owner is responsible for the change's success, not just submitting the request.
CAB = Governance body that approves changes. Know that it includes representatives from multiple areas (IT, security, business).
Stakeholders include anyone AFFECTED by the change, not just those implementing it.
Emergency changes still need approval—just expedited. They also require retroactive CAB review.
Standard changes are pre-approved and don't need individual CAB review, but must follow documented procedures exactly.

Memory Trick

"OWN-STAKE-APPROVE"

  • OWNership — Someone is accountable
  • STAKEholders — Affected parties involved
  • APPROVE — Formal authorization given
  • CAB Composition Memory:
  • "BITES" the change:
  • Business representatives
  • IT/Technical representatives
  • The change manager
  • Executives (for high-risk)
  • Security representative
  • Approval Level Memory:
  • Standard = Pre-approved (simple)
  • Normal = CAB review (typical)
  • Emergency = Fast approval, document later (urgent)

The Golden Rule: If it affects someone, they should know about it (and probably approve it).

Test Your Knowledge

Q1.Who is ultimately accountable for ensuring a change is properly tested and implemented?

Q2.A change will affect the company's customer-facing website. Which stakeholder should be consulted but is often overlooked?

Q3.What happens to emergency changes that bypass the normal CAB review process?

Want more practice with instant AI feedback?

Practice with AI

Continue Learning

Ready to test your knowledge?

Practice questions on change approval process and other Objective 1.3 concepts.

Start Practice