CHNG-15

Do procedures exist to provide that emergency changes are documented and authorized (including after-the-fact approval)?

Explanation

This question is asking whether your organization has formal procedures for handling emergency changes to your systems, with a specific focus on documentation and authorization processes. An emergency change is a modification that must be implemented urgently, often to address critical security vulnerabilities, fix severe bugs causing service outages, or respond to other high-priority incidents where the normal change management process would take too long. Because emergency changes bypass standard review processes, they introduce higher risk. The security assessment is asking this because: 1. Emergency changes can introduce significant security risks if not properly managed 2. Without documentation, organizations may not know what was changed during an emergency 3. Without authorization (even after-the-fact), emergency changes could be used to circumvent security controls 4. Auditors need to verify that emergency changes were legitimate and properly handled A good answer should describe: - Your formal procedure for emergency changes - How emergency changes are documented - Who can authorize emergency changes - The process for after-the-fact review and approval - How you track and audit emergency changes Even if you need to make emergency changes quickly, you should still have governance around the process to maintain security and compliance.

Example Responses

Example Response 1

Yes, we maintain formal emergency change management procedures When an emergency change is required, the engineer must first notify the on-call manager who provides verbal approval The engineer then implements the change and documents it in our ticketing system within 4 hours, including the nature of the emergency, what was changed, who made the change, and the impact Within 24 hours, the change undergoes a formal retrospective review by our Change Advisory Board (CAB), which includes security, operations, and development representatives This review ensures the change was appropriate, properly implemented, and that root causes are addressed All emergency changes are logged in our change management database and flagged for audit purposes In the past year, we've had 7 emergency changes, all of which followed this process.

Example Response 2

Yes, our organization has a dedicated Emergency Change Management Policy that outlines procedures for urgent system modifications When an emergency change is needed, the requester must contact the IT Security Officer or CTO for verbal authorization before proceeding During implementation, the engineer must document their actions in real-time in our ServiceNow platform Within 48 hours of the change, the requester must complete a formal Emergency Change Request form detailing the issue, actions taken, systems affected, and business justification This form is reviewed by our Emergency Change Committee at their weekly meeting, where they provide official after-the-fact approval or recommend additional remediation steps All emergency changes are tagged in our configuration management database and included in monthly security reports to leadership.

Example Response 3

No, we don't currently have formal procedures specifically for emergency changes Our standard change management process requires all changes to go through the Change Advisory Board, which meets weekly For urgent issues, we have an informal understanding that senior developers or operations staff can make necessary changes to restore service, but we don't have documentation requirements or a formal after-the-fact approval process We recognize this is a gap in our change management framework and are developing an Emergency Change Policy that will include documentation templates, authorization requirements, and a retrospective review process We expect to implement this new policy within the next quarter to address this compliance requirement.

Context

Tab
Organization
Category
Change Management

ResponseHub is the product I wish I had when I was a CTO

Previously I was co-founder and CTO of Progression, a VC backed HR-tech startup used by some of the biggest names in tech.

As our sales grew, security questionnaires quickly became one of my biggest pain-points. They were confusing, hard to delegate and arrived like London busses - 3 at a time!

I'm building ResponseHub so that other teams don't have to go through this. Leave the security questionnaires to us so you can get back to closing deals, shipping product and building your team.

Signature
Neil Cameron
Founder, ResponseHub
Neil Cameron