Feature Request: Expiration and Review Lifecycle for Administrative Exceptions
under review
T
Timothy Cogar
Issue
Lightspeed Filter allows administrators to create exceptions and configuration objects that may remain in place indefinitely unless someone manually reviews and removes them.
This is particularly important for objects such as:
Access List entries;
SSL bypass entries;
custom categories;
temporary allow/block exceptions;
vendor-specific exceptions.
An exception may be appropriate when created but no longer necessary months or years later.
Without lifecycle controls, temporary changes can effectively become permanent simply because their original purpose is forgotten.
WCPSS already has a related governance concern with SSL List entries, where external tracking is necessary to document why entries exist and whether they remain needed.
Requested Enhancement
Allow administrators to optionally assign lifecycle metadata to applicable configuration objects.
Suggested fields include:
Review Date
Expiration Date
Business/Technical Owner
Purpose / Justification
Ticket or Change Reference
Notes
These fields should be optional so permanent entries are not forced into an expiration model.
Review Date
A review date should indicate that an entry must be evaluated but should not automatically remove it.
Example:
Domain: vendor-example.com
Purpose: Temporary instructional pilot
Review Date: October 30, 2026
When the date approaches, Lightspeed could identify the entry as:
Review Due
The administrator could then:
extend the review date;
confirm the entry remains valid;
modify it;
remove it.
Expiration Date
Where appropriate, administrators should also be able to specify an actual expiration date.
Possible administrative behavior could include:
automatically disable the entry;
automatically remove it;
require confirmation before removal;
notify administrators and place it into an Expiring status.
Districts should be able to select the preferred behavior.
Notifications
Lightspeed should support configurable notifications such as:
30 days before review;
14 days before expiration;
7 days before expiration;
expiration reached.
Notifications could appear in the console, administrative email, or scheduled governance report.
Filtering and Reporting
Administrators should be able to identify:
entries approaching expiration;
overdue reviews;
expired entries;
entries without an owner;
entries without justification;
long-standing exceptions.
Requested Outcome
Give administrative exceptions a manageable lifecycle rather than assuming every configuration entry should remain indefinitely.
The desired model is:
Create → Document → Review → Renew or Retire
Acceptance Criteria
Applicable administrative objects support optional review dates.
Applicable objects support optional expiration dates.
Administrators can record justification and ownership.
Entries approaching review or expiration can be identified.
Administrators can receive notifications.
Review does not automatically remove an entry unless configured to do so.
Expired or overdue entries can be filtered and reported.
Business Value
This would:
reduce obsolete exceptions;
improve security governance;
simplify periodic audits;
preserve institutional knowledge;
reduce unnecessary access;
improve accountability;
reduce reliance on external tracking systems.
The principle is simple:
Exceptions should have a lifecycle, not just a creation date.
Matthew Burg
updated the status to
under review
Autopilot
Merged in a post:
Expiration and Review Lifecycle for Administrative Exceptions
T
Timothy Cogar
Issue
Filtering exceptions may remain in place indefinitely unless an administrator remembers to manually review and remove them.
This can affect:
Access List entries;
SSL bypass entries;
Custom Categories;
temporary allow/block exceptions;
vendor-specific exceptions;
other administrative exceptions.
An exception can be completely valid when created but no longer necessary six months or two years later.
Without lifecycle controls, temporary exceptions can effectively become permanent simply because their original purpose is forgotten.
Requested Enhancement
Allow applicable configuration objects to support optional lifecycle metadata.
Suggested fields include:
Review Date
Expiration Date
Business or Technical Owner
Purpose / Justification
Ticket or Change Reference
Administrative Notes
These fields should be optional so permanent configuration objects are not forced into an expiration model.
Review Dates
A review date should indicate that an entry requires evaluation without automatically removing it.
Example:
Domain: vendor-example.com
Purpose: Temporary instructional pilot
Review Date: October 30, 2026
When the date approaches, Lightspeed could mark the entry:
Review Due
The administrator could then:
confirm it remains required;
extend the review date;
modify it;
remove it.
Expiration Dates
Where appropriate, administrators should also be able to define actual expiration behavior.
Options could include:
automatically disable;
automatically remove;
require confirmation before removal;
change status to Expired;
notify administrators without automatic action.
Districts should be able to choose the appropriate behavior.
Notifications
Support configurable reminders such as:
30 days before review;
14 days before expiration;
7 days before expiration;
expiration reached.
Notifications could be delivered through:
console alerts;
administrative email;
scheduled governance reports.
Reporting
Administrators should be able to identify:
entries approaching expiration;
overdue reviews;
expired entries;
entries without an owner;
entries without justification;
long-standing exceptions that have never been reviewed.
Requested Outcome
Give exceptions a manageable lifecycle instead of treating every configuration entry as permanent.
The preferred model is:
Create → Document → Review → Renew or Retire
Acceptance Criteria
Applicable objects support optional review dates.
Applicable objects support optional expiration dates.
Ownership and justification can be recorded.
Upcoming and overdue reviews can be identified.
Administrators can receive notifications.
Expiration behavior can be configured appropriately.
Expiring and overdue records can be filtered and reported.
Business Value
This would:
reduce obsolete exceptions;
improve security governance;
simplify periodic audits;
preserve institutional knowledge;
reduce unnecessary exposure;
improve accountability;
reduce dependence on external tracking tools.
Core principle: Exceptions should have a lifecycle, not just a creation date.