HECVAT Category
Change Management
Change Management covers controls and questions related to that domain. It outlines expectations institutions typically require from vendors. The category helps assess risk posture and operational maturity. It provides structure for consistent evaluation during security reviews.
Assessment Questions
Will the institution be notified of major changes to your environment that could impact the institution's security posture?
At issue is whether you keep clients in the loop: institutions want assurance that you will notify them of significant changes to your environment that could affect their security posture.
Does the system support client customizations from one release to another?
At issue here is whether customers can tailor the software to their needs, and whether those customizations carry forward intact when you ship new releases.
Do you have an implemented system configuration management process (e.g.,secure "gold" images, etc.)?
At issue is whether you run a formal configuration management process, including secure baseline or "gold" images that keep systems built to a known, hardened standard.
Do you have a documented change management process?
Change management discipline is the focus here: assessors look for a formal, documented process governing changes to your IT systems, applications, infrastructure, and other technology assets.
Does your change management process minimally include authorization, impact analysis, testing, and validation before moving changes to production?
At issue is the rigor of your change management process, the structured way changes to IT systems, applications, and infrastructure are introduced. Specifically, it's asking if your process includes at least four critical elements:
Does your change management process verify that all required third-party libraries and dependencies are still supported with each major change?
At issue is whether your change management process includes a specific step to confirm that all third-party libraries and dependencies remain actively supported and maintained whenever a major change is made.
Do you have policy and procedure, currently implemented, managing how critical patches are applied to all systems and applications?
Reviewers are looking for proof that critical patches aren't just covered on paper but governed by a policy and procedure you actively follow across every system and application.
Have you implemented policies and procedures that guide how security risks are mitigated until patches can be applied?
Reviewers want assurance that you can hold the line during the gap between discovering a vulnerability and patching it, through formal, documented risk-mitigation procedures.
Do clients have the option to not participate in or postpone an upgrade to a new release?
Reviewers want to know how much control clients have over upgrade timing, specifically whether new releases can be applied to their environments on their schedule. In a security assessment context, this question evaluates the balance between keeping systems updated with security patches and respecting client operational needs.
Do you have a fully implemented solution support strategy that defines how many concurrent versions you support?
Version support is the focus of this item: assessors want to know that you have a defined strategy spelling out how many concurrent versions of your software you keep supported at once.
Do you have a release schedule for product updates?
Predictable delivery of product updates is what's being probed here, specifically whether your organization follows a structured, repeatable release schedule. A release schedule is a documented timeline that outlines when software updates, patches, bug fixes, and new features will be deployed to production environments.
Do you have a technology roadmap, for at least the next two years, for enhancements and bug fixes for the solution being assessed?
A forward-looking technology roadmap is the focus here: assessors want to see documented plans for enhancements, new features, and bug fixes extending at least two years out.
Can solution updates be completed without institutional involvement (i.e., technically or organizationally)?
Reviewers want to know whether you can roll out updates to your solution independently, without requiring any technical or organizational involvement from the institution.
Are upgrades or system changes installed during off-peak hours or in a manner that does not impact the customer?
At issue is the timing and execution of maintenance, specifically whether upgrades and system changes happen during off-peak windows or in ways that shield customers from disruption.
Do procedures exist to provide that emergency changes are documented and authorized (including after-the-fact approval)?
Emergency changes are the concern here, since urgent fixes still need formal procedures that capture documentation and authorization, even when approval comes after the fact.
Do you have a systems management and configuration strategy that encompasses servers, appliances, cloud services, applications, and mobile devices (company and employee owned)?
Assessors want assurance that you manage and configure your entire technology estate consistently, spanning servers, appliances, cloud services, applications, and both company- and employee-owned mobile devices. A systems management and configuration strategy refers to the documented approach, policies, procedures, and tools used to maintain, update, and secure all technology components.
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.
