Seeking Advice: Managing Accessibility Exceptions Related to Website CIs

[MitchPautz]

I'd appreciate input from this community on a design question we're working through.

 

TL;DR: We’re considering moving accessibility exception management off the Website CI and into a request/exception process linked to the CI. The goal is to preserve the CMDB as the system of record for the website while using a separate process record to manage approvals, denials, decision dates, expiration dates, and history. I’m looking for feedback on whether this separation aligns with CMDB/ServiceNow best practices and how others are handling similar time-bound governance exceptions.

 

The business requirement

We maintain websites as CIs in the CMDB. Our accessibility team has a process where a website can request an exception from an accessibility requirement.

The business needs to track:

• The website associated with the request

• Whether the exception was approved or denied

• The decision date

• The expiration date for approved exceptions

• Historical decisions, including denied and expired exceptions

• Upcoming exception expirations for reporting and follow-up

Approved exceptions are normally valid for two years from the decision date.

 

Current approach

Today, the Website CI contains an Accessibility Exception field and an Exception Expiration Date. Authorized staff update these fields directly on the CI.

The new requirement would require additional information, such as decision status and decision date, and potentially additional access controls so the group administering accessibility exceptions can maintain those attributes.

 

Our concern

As the CMDB owner, I'm hesitant to continue adding process-specific fields and granting additional groups direct write access to CI records.

The accessibility exception seems less like an attribute of the CI and more like a governance decision with its own lifecycle that happens to apply to a CI.

I'm also considering the longer-term precedent. Accessibility exceptions may not be the only governance process that needs to associate approvals, waivers, expiration dates, or other decisions with CIs. I don't want the CI record to gradually become the system of record for multiple governance workflows.

 

High-level approach we're considering

Rather than adding additional fields to the Website CI, we're considering using the ServiceNow request process.

Conceptually:

Accessibility Exception Request → RITM/Task → Website CI

A customer would submit an Accessibility Exception Request and identify the applicable Website CI.

The request/workflow would capture the justification and supporting information and route it to the appropriate group for review.

The resulting process record would capture the decision, decision date, approver, and other lifecycle information. If approved, ServiceNow would calculate the expiration date based on the two-year policy.

This would also allow us to retain the complete history of approved, denied, expired, and renewed exception requests without maintaining that history directly on the CI.

The Website CI would remain associated with the exception through a reference/relationship, while the exception process owners would primarily require access to the request/exception records rather than write access to the CI.

We're intentionally treating this as a functional and architectural direction rather than prescribing RITM/business rules as the technical solution. A dedicated exception table or an existing ServiceNow capability such as IRM/GRC Policy Exception Management could potentially be a better implementation depending on licensing, scale, and requirements.

 

Questions for the community

Does this separation align with CMDB and ServiceNow best practices you've used or seen elsewhere?

In particular, I'm interested in how others draw the boundary between:

Attributes describing the CI
versus
Governance/process records describing decisions made about the CI.

For organizations managing things like accessibility exceptions, security exceptions, policy waivers, risk acceptances, or similar time-bound exceptions:

• Do you store the current exception status directly on the CI?

• Do you maintain a separate exception/request record related to the CI?

• Have you successfully used Catalog/RITM for this type of lifecycle?

• At what point would you recommend a dedicated exception table or ServiceNow IRM/GRC capability instead?

• How do you make the current exception status easily visible from the CI without making the CI itself the system of record for the exception?

Our current thinking is:

The CMDB should describe the managed object, while the governance process should own the decisions and lifecycle associated with exceptions for that object.

I'd appreciate hearing how others have approached this and any lessons learned, particularly around reporting, access control, renewals/expiration, and keeping the CMDB model maintainable over time.

Thank you for your time