IT Change ManagementProcess, Change Advisory Board, Risk Scoring, and a Template for Regulated Businesses
IT change management is the documented process for requesting, assessing, approving, scheduling, implementing, and reviewing every change to production systems so that nothing reaches a server, firewall, cloud tenant, or application without a known owner, a tested plan, and a way back. Petronella Technology Group has run change control for regulated businesses in Raleigh and across North Carolina since 2002, and this page explains the process we use, the change types and approval paths, how a change advisory board works, and a template you can adopt this week.
- IT change management is a control, not paperwork. Its job is to make sure every production change has an owner, an assessed risk, an approval matched to that risk, a tested rollback, and a record. The ticket is the evidence, not the point.
- Most change programs fail on classification, not approval. If every change goes to the same board, the board becomes a bottleneck and engineers route around it. Standard, normal, and emergency changes need three different paths.
- Regulators already require it. NIST SP 800-171 control 3.4.3 (CMMC practice CM.L2-3.4.3), SOC 2 criterion CC8.1, PCI DSS requirement 6.5.1, and ISO 27001 Annex A control 8.32 each call for tracked, reviewed, and approved changes with security impact analysis.
- A change advisory board should meet weekly for twenty minutes. Its work is done in advance by risk scoring and a standard-change catalog; the meeting confirms, schedules, and records.
- The post-implementation review is where the process earns its keep. A change that failed silently and was never reviewed will fail the same way again, usually during an audit.
What Is IT Change Management?
IT change management is the discipline of controlling modifications to the technology environment a business depends on: servers, network equipment, cloud services, identity systems, security tools, and the applications that run on them. A change is anything that alters the configuration, code, or capacity of a production system. Patching a domain controller, opening a firewall port, adding a SaaS integration, migrating a mailbox, and changing a backup schedule are all changes. The process exists to answer five questions before any of them happens: what is changing, why, what could go wrong, who approved it, and how do we undo it.
The term comes from the IT service management tradition, where ITIL defines change enablement as the practice that maximizes the number of successful changes by ensuring risks are properly assessed, authorizing changes to proceed, and managing a change schedule. That definition is still the right one. What has shifted is the environment. A business in 2026 changes its production systems dozens of times a week through automatic updates, SaaS releases, infrastructure-as-code, and managed service provider tooling, and most of those changes never get a ticket. A modern change management process has to decide, deliberately, which of those changes need human review and which can be pre-approved and logged.
Petronella Technology Group has provided managed IT, cybersecurity, and compliance services from Raleigh, North Carolina since 2002. Change control is built into every managed environment we operate because it is the control that most other controls depend on: you cannot maintain a hardened baseline, prove patch compliance, or investigate an incident if you cannot say what changed and when. The process on this page is the one our engineers follow, adapted for businesses that need it to satisfy CMMC, HIPAA, SOC 2, or PCI DSS assessors as well as keep the lights on.
- A gate between an idea and a production system, sized to the risk of the change
- A classification scheme: standard, normal, and emergency changes with different approval paths
- A risk and impact assessment recorded before approval, not reconstructed afterward
- A schedule that keeps risky changes out of business hours and away from each other
- A record that an auditor, an engineer at 2 a.m., or an incident responder can read and trust
- Not a monthly meeting that approves everything on the list without reading it
- Not a form so heavy that engineers make the change first and file the ticket later
- Not organizational change management, which handles how people adopt new tools and processes
- Not release management or a software development pipeline, though both feed changes into it
- Not something a small business can skip; a five-person firm with one server still needs to know who changed the firewall rule
Standard, Normal, and Emergency Changes: The Classification That Makes the Process Work
Classification is the decision that determines whether a change management program survives contact with a real IT team. If every change takes the same path, the path becomes either a rubber stamp or a bottleneck. The three ITIL change types, plus the major change designation many organizations add, give each change an approval route proportional to its risk.
The most common classification mistake is treating the standard-change catalog as optional. Without it, routine work like patching gets logged as a normal change, the weekly queue fills with dozens of identical low-risk tickets, and the board stops reading them. The second most common mistake is the opposite: letting engineers self-declare changes as standard when no runbook exists. A standard change is one the board has reviewed and pre-approved as a category, with a written procedure behind it. Our IT runbook template covers what that written procedure should contain.
The IT Change Management Process in Eight Steps
The steps below are the change lifecycle Petronella Technology Group follows in managed environments. They map directly to what ITIL describes and to what CMMC, SOC 2, and PCI DSS assessors ask to see. Each step produces a specific artifact; the artifacts together are the change record.
Request: the requester records what will change, why, which systems and users are affected, and the desired date
Classify: the change manager assigns standard, normal, major, or emergency, and routes the request accordingly
Assess: risk, impact, and security consequences are scored, and dependencies on other systems and scheduled changes are identified
Plan: the implementer writes the implementation steps, the test that proves success, the rollback procedure, and the communication plan
Approve: the change manager or the change advisory board approves, rejects, or returns the request with questions, and the decision is recorded
Schedule: the change is placed in a maintenance window on the change calendar, checked for collisions, and announced to affected users
Implement: the plan is executed as written, the success test is run, and the result (success, partial, rolled back) is logged with timestamps
Review: a post-implementation review confirms the outcome, captures what deviated from plan, and closes the record or opens a follow-up
Step 3 deserves the most attention. The assessment is where change management stops being a form and becomes a control. A good assessment states the blast radius (which users, which systems, which business processes stop if this goes wrong), the likelihood of failure based on how many times this kind of change has been done before, the security impact (does this open a port, grant a privilege, change logging, or alter a baseline configuration), and the dependencies (is anything else changing in the same window, and does a backup need to complete first). NIST SP 800-171 control 3.4.4 requires exactly this security impact analysis before implementation, and it is the part of the record CMMC assessors read most carefully. The seven-question template for that analysis, and the baselines it compares against, are on our configuration management plan page.
Step 4 is where most failed changes were doomed. A rollback plan that says "restore from backup" is not a plan unless the backup has been verified restorable and someone has timed the restore. Our engineers write the rollback with the same level of detail as the implementation, and for any change to a server or hypervisor, they take a snapshot or confirm a fresh backup as the first implementation step. The server management services page describes how that backup verification runs continuously rather than on the day of the change.
Step 8 is the step organizations skip. The post-implementation review takes five minutes for a routine change and an hour for a major one. It asks whether the change achieved its purpose, whether the implementation matched the plan, whether the time estimate was right, and whether anything should become a standard change or be added to a runbook. Skipping it means the same surprise recurs, and it means the record shows an approval with no outcome, which an auditor will read as an incomplete control.
Not Sure Whether Your Change Process Would Survive an Audit?
Bring us your last ten production changes, however they were recorded. In a short scoping call we can tell you which would pass a CMMC or SOC 2 sample, which would be findings, and what the smallest process that closes the gap looks like for a business your size.
The Change Advisory Board: Who Sits on It and How It Works
A change advisory board (CAB) is the group that reviews and approves normal and major changes and pre-approves the standard-change catalog. In a large enterprise it can be a formal committee. In a business with fifty to five hundred employees it is usually four to six people, and it works best when it is small, scheduled, and disciplined about doing its reading before the meeting.
Change manager (chair)
Owns the process, classifies incoming requests, approves low-risk normal changes alone, runs the meeting, and maintains the change calendar. In a managed IT engagement this is typically the provider's service delivery lead, with the client retaining approval authority.
Technical leads
The people who can judge whether a plan is realistic: the network lead, the systems lead, the application owner. They assess risk and dependency, not business priority. Petronella Technology Group engineers fill these seats for the systems we manage.
Security representative
Reviews the security impact of every change: new ports, new privileges, logging changes, baseline deviations, and anything touching identity or backups. For CMMC environments this is the person who confirms the change does not move CUI outside the assessed boundary.
Business representative
An operations or department leader who knows when the business cannot tolerate downtime: payroll runs, month-end close, clinic hours, shipping cutoffs. This seat prevents technically perfect changes from landing at the worst possible moment.
Compliance owner (as needed)
For regulated businesses, the person responsible for the compliance program attends when a change affects a control, a policy, or an assessed system. They confirm the change record will serve as evidence and that any affected policy is updated.
Emergency CAB
Two named people, one technical and one with business authority, reachable by phone at any hour. They approve emergency changes verbally, the approval is logged immediately, and the full record is completed within one business day and reviewed at the next regular meeting.
A standing CAB agenda that fits in twenty minutes
The board meets weekly, at the same time, whether or not there are many changes to review. The agenda is fixed: review the outcome of last week's changes, including any that failed or were rolled back; walk the new normal and major requests, each already scored and read in advance, and approve, reject, or return them; confirm the schedule for the coming week and check it for collisions with each other and with business events; and review any emergency changes since the last meeting. Once a quarter, the board also reviews the standard-change catalog and removes or adds entries. The meeting is short because the work of assessment happened in the ticket. When a CAB meeting runs for two hours, it is doing assessment work that should have been done before it convened.
How to Score Change Risk and Impact
Risk scoring is what lets a change manager approve most normal changes alone and reserve the board for the ones that need it. The scheme does not need to be complicated. Two questions, each answered on a three-point scale, produce a matrix that routes every change to the right approval and the right window.
Two modifiers override the matrix. Any change that touches a security control (firewall policy, logging, backup, multi-factor authentication, privileged accounts, endpoint protection) is at least medium risk regardless of scope, because the failure mode is silent rather than an outage. Any change scheduled within a change freeze (the days around a payroll run, a product launch, a clinic's busiest week, or a holiday weekend when staff are thin) needs CAB approval regardless of score. The scoring is written into the request form so the requester does the first pass and the change manager confirms it.
What Changes When Change Management Is Real
"Who changed the firewall?"
An application stops working on a Tuesday morning. Three people could have made the change. Nobody remembers, there is no log, and the fix is to guess until it works. The root cause is never recorded.
Patch Tuesday is a surprise
Updates apply whenever the vendor pushes them. A cumulative update breaks a line-of-business application during business hours, and the helpdesk learns about it from twenty tickets.
Rollback means "restore from backup"
The backup has never been test-restored. The restore takes eleven hours instead of the one hour everyone assumed, and the business is down for a day.
The auditor asks for change records
The answer is a folder of emails and a chat history. The assessor samples five changes and cannot find approval or testing for any of them. Change management is written up as a finding.
Every change has a record
The firewall rule shows up in the change log with a requester, an approver, a timestamp, and the ticket that explains why. The outage is traced in minutes and the rule is corrected through a documented emergency change.
Patching is a standard change with a window
Workstations patch through the RMM platform on a schedule the board approved once. Servers patch in a documented window with a snapshot first. The post-run report is the compliance evidence.
Rollback is rehearsed
Backups are verified restorable every week. For any server change, a snapshot is step one of the runbook, and the rollback has a time estimate that has been measured, not assumed.
The audit sample passes
The assessor picks five changes at random and finds a request, an assessment, an approval, an implementation log, and a review for each one, exported from the ticketing system and stored in ComplianceArmor® alongside the policy.
Change Management Requirements in CMMC, HIPAA, SOC 2, PCI DSS, and ISO 27001
Change management is one of the few controls that appears, in nearly the same form, in every major framework. That makes it unusually efficient to get right: one process, one set of records, and evidence that serves several assessments at once. Here is where each framework asks for it and what the assessor will sample.
CMMC Level 2 and NIST SP 800-171
Control 3.4.3 requires organizations to track, review, approve or disapprove, and log changes to organizational systems. Control 3.4.4 requires analyzing the security impact of changes before implementation, and 3.4.1 requires maintaining baseline configurations that change control protects. CMMC practices CM.L2-3.4.3 and CM.L2-3.4.4 are assessed by examining change records and interviewing the people who approve them. Craig Petronella, CMMC Registered Practitioner and author of the CMMC 2.0 Certification Guide, has seen this family fail assessments for one reason above all others: changes were made, but no record shows they were reviewed before they happened. Our CMMC compliance services build the change record into the system security plan from the start.
HIPAA Security Rule
HIPAA does not use the phrase "change management," but 45 CFR 164.308(a)(8) requires periodic technical and nontechnical evaluation in response to environmental or operational changes affecting the security of electronic protected health information, and the risk analysis standard expects the covered entity to know when its environment changed. In practice, a healthcare practice that cannot produce change records cannot show its risk analysis is current. See our HIPAA compliance services for how the two fit together.
SOC 2 (Trust Services Criteria)
Common criterion CC8.1 states that the entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. A SOC 2 Type II auditor samples changes across the observation period and expects to see each of those verbs evidenced. Our SOC 2 compliance services map the eight-step process on this page to CC8.1 directly.
PCI DSS v4.0
Requirement 6.5.1 requires that changes to all system components in the production environment are made according to established procedures that include reason for and description of the change, documented security impact, documented approval by authorized parties, testing to verify the change does not adversely affect security, and procedures to address failures and return to a secure state. That list is, almost word for word, the change record template further down this page.
ISO/IEC 27001:2022
Annex A control 8.32 (Change management) requires that changes to information processing facilities and information systems be subject to change management procedures. The certification auditor looks for the documented procedure, evidence it is followed, and evidence that emergency changes are reviewed after the fact. Control 8.9 (Configuration management) depends on it.
Evidence in ComplianceArmor®
The ComplianceArmor® platform holds the change management policy, the standard-change catalog, and the exported change records as evidence mapped to each framework's control. When an assessor asks for CM.L2-3.4.3 or CC8.1 evidence, the answer is a filtered export rather than a search through email. Details are on the ComplianceArmor® platform page.
IT Change Management Template: The Change Record and the Policy Outline
The template has two parts. The change record is the form every normal, major, and emergency change fills in, and it doubles as the audit evidence. The policy outline is the two-page document that authorizes the process, names the roles, and defines the change types. Both are written to satisfy the frameworks above without any framework-specific language, so one document serves every assessment.
- Identification: change ID, title, requester, date submitted, change type (standard, normal, major, emergency), category (network, server, cloud, identity, application, security tool, facility)
- Description and reason: what is changing in plain language, the business or technical reason, and the ticket, project, or vulnerability it traces to
- Scope and impact: systems affected (by asset ID from the inventory), users and departments affected, expected downtime, and business processes interrupted
- Risk assessment: impact score, likelihood score, resulting risk level, security impact analysis (ports, privileges, logging, baselines, data location), and dependencies on other changes or backups
- Implementation plan: numbered steps or a link to the runbook, the implementer, the estimated duration, and the pre-change checks (backup verified, snapshot taken, maintenance mode set)
- Test plan: the specific check that proves success, who performs it, and what result is expected
- Rollback plan: numbered steps to return to the previous state, the trigger for invoking it, the measured time it takes, and who decides
- Communication plan: who is notified before, during, and after, through which channel, and the wording of the user-facing notice
- Approval: approver name, role, date, decision (approved, rejected, returned), and conditions attached
- Schedule: planned window start and end, change freeze check, collision check against the change calendar
- Implementation log: actual start and end, result (success, partial, rolled back), deviations from plan, and evidence attached (screenshots, command output, monitoring confirmation)
- Post-implementation review: objective met (yes or no), lessons learned, follow-up actions, candidate for standard catalog (yes or no), closed by and date
- Purpose and scope: which systems and environments the policy covers (production, and whether test and development are included), and which frameworks it satisfies
- Definitions: what counts as a change; the standard, normal, major, and emergency types with the criteria for each
- Roles: change manager, change advisory board membership, emergency CAB, implementers, requesters, and the authority each holds
- Process: the eight steps with the artifact each produces and the system of record (ticketing platform) where it lives
- Risk assessment method: the impact and likelihood scales, the matrix, and the modifiers for security controls and change freezes
- Standard-change catalog: how entries are proposed, approved, and reviewed quarterly, and the requirement that each has a runbook
- Scheduling rules: maintenance windows, change freezes, notice periods for user-facing changes, and the collision rule
- Emergency changes: the approval path, the one-business-day completion rule, and mandatory review at the next CAB
- Records and retention: what is retained, for how long (at least the longest assessment period you are subject to), and how it is exported as evidence
- Exceptions and enforcement: how an unauthorized change is handled when discovered, and the review that follows
- Review cadence: annual policy review, owner, and approval signature
The record depends on two other documents existing: an asset inventory so that "systems affected" can be stated precisely, and runbooks so that "implementation plan" can be a link rather than a fresh essay. If you are building change management from nothing, build those first. Our IT asset management and IT documentation pages cover both, and the employee offboarding checklist is a worked example of a standard change with a runbook behind it.
Six Ways IT Change Management Programs Fail
The process is heavier than the risk
A one-size form with fourteen required fields for every change, including adding a printer, teaches engineers that the process is an obstacle. They make the change and file the ticket afterward, or not at all. The fix is the standard-change catalog and a request form whose required fields scale with the risk score.
Automatic changes are invisible
Vendor auto-updates, SaaS releases, and managed service provider tooling change production constantly. If the policy pretends they do not exist, the change log is a fiction. The fix is to classify each automated change stream as a standard change, decide which need a window, and log what the tooling did. Our remote monitoring and management page explains how patch reporting becomes that log.
The CAB approves without reading
A board that meets monthly with forty items on the agenda approves them all in an hour. Approval without assessment is worse than no process, because the record claims a review that did not happen. Weekly, short, and pre-read is the fix.
Rollback is theoretical
The rollback plan is one sentence and has never been executed. When the change fails, the team discovers the snapshot was not taken, the backup is corrupt, or the restore takes all night. Rehearsed rollback and verified backups are the fix, and for servers the snapshot is step one of every runbook.
Emergency becomes the default
When the normal path is slow, everything becomes an emergency. If more than a small fraction of changes in a quarter are emergencies, the normal path is broken, not the engineers. The fix is a faster normal path for low-risk changes and a board that reviews every emergency after the fact.
Nobody reviews outcomes
Changes are approved and implemented, and the record ends there. Failed changes are not analyzed, time estimates never improve, and the standard catalog never grows. The post-implementation review is the step that turns the process into a learning system rather than a filing system.
How Petronella Technology Group Runs Change Management for Clients
Petronella Technology Group was founded in Raleigh in April 2002 as a managed IT provider and has held a BBB A+ rating since 2003. Today managed IT is offered selectively, as a security-led service for businesses with compliance obligations, and change control is one of the disciplines that distinguishes it from commodity IT support. Every environment we manage runs the process on this page. Here is what that looks like in practice.
- A change management policy and standard-change catalog written for your environment and your frameworks, stored in ComplianceArmor® as controlled documents
- A ticketing system of record where every normal, major, and emergency change follows the record template above, with approval workflows matched to the risk matrix
- A weekly change advisory board, chaired by our service delivery lead, with your technical, security, business, and compliance seats filled by your people or ours as you prefer
- Patch management as a standard change: workstations on an approved schedule through the RMM platform, servers in documented windows with snapshots first, and post-run reports retained as evidence through our patch management service
- Runbooks for every standard change and every recurring normal change, maintained as part of the documentation set
- Verified-restorable backups checked on a schedule, so the rollback plan on every server change is real
- Quarterly exports of change records mapped to CMMC, HIPAA, SOC 2, PCI DSS, or ISO 27001 controls, ready for the assessor
- Emergency change support around the clock, with the two-person emergency board reachable by phone and every emergency reviewed at the next weekly meeting
- Craig Petronella, founder and CEO, is a CMMC Registered Practitioner, an NC Licensed Digital Forensics Examiner (License 604180-DFE), and MIT-certified in cybersecurity. His forensics work is where the value of a change log becomes concrete: an investigation that can say what changed and when finishes in days, and one that cannot may never finish.
- Craig's book IT Buyers Guide lays out sixteen questions to ask before signing an IT contract; whether the provider follows a documented change process, and whether you can see the records, is among the first. His book Peace of Mind Computer Support describes what dependable support looks like from the client's side, and predictable change windows are a large part of it.
- "We have been working with Craig and his team for more than 16 years for all of our company's computer, network and IT Support needs. Our confidence level has allowed us to recommend Petronella Technology Group to long time business partners." (Vanessa Jenkins, construction company, verified review)
- Rated 4.7 across 92 verified TrustIndex reviews and 5.0 across 15 Google reviews
- Founded 2002, BBB A+ since 2003, CyberAB Registered Provider Organization #1449
- Managed IT intake is selective and by waitlist, so that every environment we take on gets the change discipline described here rather than a stretched helpdesk
For businesses that keep internal IT staff, the same process runs in a co-managed IT arrangement: your team implements and sits on the board, and we provide the change manager role, the tooling, the runbooks, and the evidence exports. For a business in the Triangle that wants the whole discipline handled, the managed IT services Raleigh page describes the full service, and the managed IT services guide explains how change control fits among the other core disciplines of a managed environment.
No Process vs. Ticket-Only vs. a Change Management Program
Most businesses sit in the middle column: changes get a ticket, but the ticket is a work order rather than a control. The right column is what the frameworks require and what the process on this page produces.
IT Change Management: Frequently Asked Questions
What is the IT change management process in simple terms?
It is the set of steps a change to a production system goes through before, during, and after it happens: someone requests it, it is classified by risk, the risk and impact are assessed, a plan with a test and a rollback is written, an authorized person or board approves it, it is scheduled in a window, it is implemented and the result logged, and it is reviewed afterward. The purpose is to make sure nothing changes without an owner, an assessment, an approval, and a record.
What is the difference between a standard change and a normal change?
A standard change is low risk, repeatable, and has already been approved as a category by the change advisory board, so individual instances do not need approval, only a log entry. Routine patching and new-user provisioning are typical examples. A normal change is anything not pre-approved: it needs its own request, assessment, plan, and approval before it is scheduled. Emergency changes are a third type, approved quickly by a small emergency board to restore service or close an active threat, and reviewed afterward.
What does a change advisory board do?
A change advisory board reviews and approves normal and major changes, pre-approves the standard-change catalog, confirms the change schedule and checks it for collisions, and reviews the outcome of recent changes including any emergencies. In a small or mid-sized business it is four to six people: a change manager who chairs it, technical leads, a security representative, a business representative, and a compliance owner when needed. It works best meeting weekly for about twenty minutes with the assessment work done in the tickets beforehand.
Does CMMC require change management?
Yes. CMMC Level 2 practice CM.L2-3.4.3, from NIST SP 800-171 control 3.4.3, requires organizations to track, review, approve or disapprove, and log changes to organizational systems. Practice CM.L2-3.4.4 requires analyzing the security impact of changes before implementation, and CM.L2-3.4.1 requires maintaining the baseline configurations that change control protects. Assessors examine change records and interview approvers, so the evidence has to show review before implementation, not just a log after the fact.
How is change management different from patch management?
Patch management is one category of change: applying vendor updates to operating systems, firmware, and applications. Change management is the process that governs all changes, including patches. In a well-run environment, routine patching is a standard change with an approved schedule and a runbook, while unusual patches such as an out-of-band fix for an actively exploited vulnerability go through the emergency path. The patch reports from the RMM platform become the implementation log for the standard change.
How much process does a small business need?
Less than an enterprise, but not none. A business with one server, a firewall, a cloud tenant, and thirty users needs a written policy of two pages, a change record for anything that is not routine, a standard-change catalog covering patching and user provisioning, a named approver, and a weekly fifteen-minute check-in that reviews what changed and what is scheduled. That is enough to satisfy a SOC 2 or CMMC assessor and, more importantly, enough to answer "what changed?" when something breaks.
What should an IT change request form include?
At minimum: a description of the change and the reason for it, the systems and users affected, a risk and impact score with a security impact analysis, an implementation plan or a link to the runbook, a test that proves success, a rollback plan with a time estimate, a communication plan for affected users, the approver and approval date, the scheduled window, an implementation log with the actual result, and a post-implementation review. That list matches what PCI DSS requirement 6.5.1 and SOC 2 criterion CC8.1 expect to see in the record.
Does Petronella Technology Group provide change management as a service?
Yes, as part of managed IT and co-managed IT engagements. We write the change management policy and standard-change catalog for your environment, run the ticketing workflow, chair a weekly change advisory board, handle patching as a standard change with documented windows, maintain runbooks and verified backups so rollback is real, and export change records mapped to CMMC, HIPAA, SOC 2, PCI DSS, or ISO 27001 controls through ComplianceArmor®. Managed IT intake is selective and by waitlist. Call 919-348-4912 or schedule a free consultation to discuss your environment.
Related Managed IT and Compliance Pages
IT Runbook Template
→IT Documentation
→IT Asset Management
→Patch Management
→Business Technology Assessment
→Managed IT Services Guide
→ComplianceArmor® Platform
→All Managed IT Services
→Last Updated: September 10, 2026 (first published September 8, 2026). This page references ITIL 4 change enablement, NIST SP 800-171 controls 3.4.1, 3.4.3, and 3.4.4, CMMC 2.0 Level 2 practices CM.L2-3.4.1, CM.L2-3.4.3, and CM.L2-3.4.4, the HIPAA Security Rule at 45 CFR 164.308(a)(8), SOC 2 Trust Services Criteria CC8.1, PCI DSS v4.0 requirement 6.5.1, and ISO/IEC 27001:2022 Annex A controls 8.9 and 8.32. Confirm current requirement text with the issuing body before relying on it for an assessment.
Know What Changed, Before the Auditor or the Outage Asks
Petronella Technology Group has run managed IT and change control for regulated businesses since 2002, holds a BBB A+ rating dating to 2003, and is a CyberAB Registered Provider Organization. Tell us about your environment and your frameworks, and we will show you the smallest change management process that satisfies both.