Exceptions

Overview

The Exceptions page lets you manage all manual overrides applied to controls, tests, vendors, and attestations in a single workspace. It is designed for scenarios where automated results are technically correct but operationally impractical, and you need a time‑bound, auditable decision to deviate from the default outcome.

The page provides high‑level counters for control and system exceptions, plus a detailed table of every exception with its target, status, owner, reason, and expiration date.

What is an exception?

An exception is a formally documented, time‑bound decision to deviate from a policy, standard, or control requirement. It is typically requested by a control owner and approved after a risk assessment, for example, allowing a legacy application to run without full MFA for 90 days while a replacement is deployed.

Key characteristics

1. Applies to an existing result (control, test, residual risk, vendor, or assessment).
2. Includes target, reason, and expiration date.
3. Temporarily overrides the default result; when it expires, the system automatically returns the result to its original state.
4. Moves through a simple lifecycle: Requested → In Review → Approved → Rejected / Returned to Default State.

What is an exclusion?

An exclusion is a permanent or predefined scope carve‑out where a policy, standard, or control does not apply. It is configured during program design, often for business, regulatory, or technical reasons.

Examples

1. Excluding all cloud resources from a test so you can focus on on‑premises systems.
2. Excluding a disaster‑recovery data center from the vulnerability‑scanning schedule because it is offline except during failover.
3. Exclusions do not change the result of a control or test; instead, they change what is in scope for that object.

Exceptions vs exclusions

Exception types and targets

You can apply exceptions to any supported result type:

1. Controls: Override the overall control results.
2. Tests: Override an automated or self-attestation test result.

For each object type, you define which result is being overridden and what the exception result should be.

Controls and tests

For a control or test, the exception can set the result to:

1. PASS
2. FAIL
3. NOT RUN
4. Unchanged (document‑only exception)

If you do not change the result, the underlying control or test outcome remains the same, and the overall program status is not affected. This is useful when you only need to document a decision or risk acceptance without altering calculated compliance status.

Exception properties

Every exception shares a common set of properties, regardless of target type:

1. Target – The object the exception applies to (control, test, risk, vendor, or assessment).
2. Target type – Category of the target, such as “Control” or “Test”.
3. System / application – The system or application associated with the target (if applicable).
4. Result being overridden – The current or default result.
5. Override value – The new result (e.g., PASS/FAIL/NOT RUN, risk score, vendor approval).
6. Owner – The primary owner responsible for the exception.
7. Reason / comment – A required or recommended description of why the exception is needed.
8. Status – Requested, In Review, Approved, Rejected, or Returned to Default State.
9. Requested by / Approved by – Who requested and who approved the exception.
10. Applied on – Timestamp for when the exception took effect.
11. Expires on – Expiration date/time when the result reverts to its original state.
12. Active / expired flag – Whether the exception is currently in force.

Exception lifecycle

1. Request an exception

Who can request: The primary owner of the object (for example, control owner, risk owner, vendor owner).

From the Exceptions page

1. Navigate to Program → Exceptions.
2. Click Add Exception.
   
3. Select the approver’s name and exception target (Control, Test, Risk, Vendor, or Assessment).
4. Choose an override value:
   1. For controls/tests: PASS, FAIL, NOT RUN, or “Leave result unchanged.”
5. Add the reason.
6. Set the timeframe:
   1. Start date (optional if effective immediately).
   2. Expiration date.
7. Provide an external ticket related to the exception, if any
8. Click Request Exception.

Once submitted, the exception status becomes Requested and appears in the Exceptions table.

2. Notification

When an exception is requested:

1. The compliance admin (or designated approver group) receives an email notification that a new exception is pending review.
2. The exception appears in the Exceptions table with status Requested, showing the target, requested change, owner, reason, and expiry date.

Email routing and approver roles are managed via your standard TrustCloud user and notification configuration.

3. Review and approval

Who can approve: Compliance administrators or users with the appropriate approval role.

Steps:

1. Open Program → Exceptions.
2. Filter by Pending / Requested exceptions.
3. Click the exception to open details.
4. Review:
   1. Target and current result.
   2. Requested override value.
   3. Reason and business justification.
   4. Timeframe and expiry.
5. Decide:
   1. Approve – the exception status changes to Approved, and the result on the target object is updated to the override value.
   2. Reject / Return to Default – the exception status changes to Rejected or Returned to Default State, and the target result remains or is set back to the original value.

Upon approval or rejection, the requester can receive an email notification depending on your notification preferences.

4. Active, modified, and expired exceptions

Once approved:

1. The exception is marked Active until the expiration date.
2. The target object displays the overridden value and may show an indicator that the result is exception‑driven.

You can:

1. Modify an existing exception to:
   1. Change the expiry date.
   2. Update the override result.
   3. Please consider adding more context to the comment or reassigning the owner.
2. Delete an exception to immediately return the target result to its default state.

When the expiration date is reached:

1. The exception automatically becomes expired.
2. The target object’s result reverts to its original value.
3. The exception remains visible in the table for historical and audit purposes.

Using the Exceptions page

The Exceptions page provides administrators a centralized view of every exception in the program.

Summary tiles

At the top of the page, you’ll see high‑level counters, such as:

1. Control exceptions – total control exceptions, with breakdowns for Approved, Pending, and Expired.
2. System exceptions – exceptions created by or linked to system‑level rules, also segmented by status.

These tiles help you quickly gauge how many active exceptions you are relying on at any time.

Exceptions table

The table lists each exception with key columns, for example:

1. Target (name or ID)
2. Target type (Control, Test, Risk, Vendor, Assessment)
3. System / Application
4. Reason
5. Status (Requested, In Review, Approved, Rejected, Returned to Default, Expired)
6. Approved by
7. Expires on

From this table, you can:

1. Search by target name or owner.
2. Filter by status (e.g., only see Pending or Expired).
3. Filter by target type (controls, tests, risks, vendors).
4. Sort by expiration date to proactively manage upcoming expirations.
5. Export the list as a CSV to share with auditors or internal stakeholders.

Viewing exception details

Click any row in the Exceptions table to open a detail view, where you can:

1. See the full history of the exception:
   1. Who requested it and when?
   2. Who approved it and when?
   3. Any edits made to the timeframe or override results.
2. Review the current and original results, side by side.
3. Update comments or ownership.
4. Approve, reject, or delete the exception (based on permissions).

This view serves as the audit trail for each exception.

Exclusions: focusing on relevant results

While exceptions handle time‑bound overrides, exclusions help you focus your program on relevant assets by permanently adjusting control and test scope.

As a control owner, you can exclude resources such as all cloud resources from a given test to avoid noise from non‑applicable objects, for example, when a control only applies to on‑premises systems.

Typical steps to configure exclusions (current behavior):

1. Go to Program → Controls.
2. Select the control and navigate to its tests or attestations.
3. Select the tests or resources you wish to exclude.
4. Click Exclude and provide a business justification.
5. Save your changes; the exclusion remains in effect until you explicitly re‑include the control, test, or resource.

Use exclusions to design a precise scope for your compliance program, and use exceptions to handle temporary deviations within that scope.

TrustCloud API and external tools

You can manage exceptions programmatically through the TrustCloud API and integrate exception workflows with external tools such as ServiceNow.

Typical integration patterns

1. Initiate exceptions from ServiceNow
   1. A ServiceNow workflow (for example, an IRM or ITSM ticket) can call the TrustCloud API to:
      1. Create a new exception for a specific control or test.
      2. Include target ID, override value, owner, reason, and expiration date in the payload.
   2. This is ideal when operations teams identify an exception during an incident or change request and want it reflected in TrustCloud without logging in separately.
2. Approve exceptions from ServiceNow
   1. Approvers can work entirely in ServiceNow:
      1. When they approve the ServiceNow item, a workflow step calls the TrustCloud API to change the exception status from Requested → Approved (or Rejected / Returned to Default).
   2. This keeps approvals inside existing ITSM approval flows while maintaining a full audit trail in TrustCloud.
3. Delete or close exceptions from ServiceNow
   1. When a remediation ticket is completed in ServiceNow, the workflow can:
      1. Call the TrustCloud API to delete the corresponding exception.
      2. Or update its status to Returned to Default State, restoring the original result.
4. Reporting and exports
   1. Use the API to retrieve:
      1. All exceptions for a TrustCloud instance.
      2. Exceptions scoped to a specific application or system.
      3. Exceptions for a specific control or test.

These datasets can be used for dashboards, risk committee reports, or centralized GRC registers.