Policy Exception & Waiver Policy¶

Document ID: AUL-POL-07 Version: 1.0 Classification: Internal Owner: Chief Technology Officer / ISSM Effective: TBD-YYYY-MM-DD Next Review: TBD-YYYY-MM-DD

1. Purpose¶

This policy establishes the process for requesting, approving, documenting, and tracking exceptions and waivers to Aulendur Labs security policies. Exceptions are sometimes necessary due to technical constraints, mission requirements, or the organization's ~5-person scale, but they shall be controlled, time-bounded, and backed by compensating controls to maintain an acceptable security posture for CMMC 2.0 Level 2 compliance.

2. Scope¶

This policy applies to:

Personnel: All employees, contractors, and advisors who need to deviate from any Aulendur Labs security policy, standard, or procedure.
Policies: All documents in the Aulendur policy library (policies, standards, procedures). This policy does not apply to legal or regulatory requirements that cannot be waived (e.g., DFARS 252.204-7012 incident reporting timelines, ITAR export restrictions).
Systems: All systems within the scope of the Aulendur security program.

3. Roles & Responsibilities¶

Role	Responsibility
Chief Executive Officer (CEO)	Approves exceptions rated High risk or involving CUI/ITAR controls; reviews all exceptions quarterly.
Chief Technology Officer (CTO) / ISSM	Owns this policy; evaluates exception requests; approves Low and Medium risk exceptions; maintains the Exception Register.
Requestor	Submits the exception request with business justification and proposed compensating controls.
ISSO (acting: CTO/ISSM)	Validates the risk assessment and compensating control adequacy for each exception.

4. Policy Statements¶

4.1 Exception vs. Waiver¶

4.1.1 An exception is a temporary, time-bounded deviation from a policy requirement, backed by one or more compensating controls. Exceptions shall not exceed 180 calendar days without re-approval.

4.1.2 A waiver is a permanent or indefinite deviation from a policy requirement, granted only when a control is technically infeasible or operationally inappropriate for the organization's scale. Waivers shall be reviewed annually and shall be backed by compensating controls.

4.1.3 Neither exceptions nor waivers may be granted for: (a) DFARS 252.204-7012 cyber incident reporting requirements, (b) ITAR/EAR export control requirements, (c) Section 889 prohibited equipment requirements, or (d) requirements mandated by active contract terms.

4.2 Exception Request Process¶

4.2.1 The requestor shall submit an exception request to the CTO/ISSM containing:

(a) The specific policy statement(s) requiring the exception (by document ID and statement number).
(b) The business or technical justification for the exception.
(c) The systems, data, and personnel affected.
(d) The data classification of information at risk (Public, Internal, Confidential, CUI, ITAR).
(e) The proposed compensating control(s).
(f) The requested duration (not to exceed 180 calendar days for exceptions).
(g) A risk assessment: what is the likelihood and impact of exploitation during the exception period.

4.2.2 Requests shall be submitted via email to the CTO/ISSM or via a shared exception request template stored in Google Drive.

4.3 Risk Assessment and Approval¶

4.3.1 The CTO/ISSM shall assess each exception request using the risk rating matrix defined in the Risk Management Policy:

Risk Rating	Approval Authority	Maximum Duration
Low	CTO/ISSM	180 calendar days
Medium	CTO/ISSM	180 calendar days
High	CEO (with CTO/ISSM recommendation)	90 calendar days
Critical	Not grantable — remediation required	N/A

4.3.2 The CTO/ISSM shall evaluate the proposed compensating controls for adequacy. A compensating control shall: (a) reduce the residual risk to an acceptable level, (b) be implementable within the requestor's scope of authority, and (c) be verifiable by the CTO/ISSM.

4.3.3 The CTO/ISSM shall respond to exception requests within 10 business days. If the request is denied, the CTO/ISSM shall provide the rationale and, where possible, suggest alternative approaches.

4.3.4 Exceptions affecting CUI or ITAR controls shall always require CEO approval, regardless of risk rating.

4.4 Exception Register¶

4.4.1 All approved exceptions and waivers shall be recorded in the Exception Register (registers/exception-register.md, forthcoming) with: (a) exception ID, (b) policy reference, (c) justification summary, (d) compensating control(s), (e) risk rating, (f) approval authority and date, (g) expiration date, (h) review date, and (i) status (Active, Expired, Revoked, Renewed).

4.4.2 The CTO/ISSM shall review all active exceptions at least quarterly and report the exception inventory to the CEO.

4.4.3 Expired exceptions shall be closed in the register. If the underlying condition persists, a new exception request shall be submitted.

4.5 Monitoring and Renewal¶

4.5.1 The CTO/ISSM shall verify that compensating controls for each active exception remain in place and effective. Verification shall occur at least quarterly.

4.5.2 Exception renewals follow the same approval process as new requests. The renewal request shall include: (a) evidence that compensating controls have been effective, (b) an explanation of why the exception is still needed, and (c) progress toward permanent remediation, if applicable.

4.5.3 Exceptions renewed more than twice (exceeding 540 calendar days total) shall be escalated to the CEO for review, regardless of risk rating, and documented as a POA&M item.

4.6 Revocation¶

4.6.1 The CTO/ISSM may revoke an exception at any time if: (a) the compensating control fails or is not maintained, (b) the risk environment changes materially, (c) the exception is no longer needed, or (d) a security incident occurs related to the excepted control.

4.6.2 Upon revocation, the affected party shall achieve full compliance within 15 calendar days or submit a new exception request with updated compensating controls.

4.7 CMMC Assessment Considerations¶

4.7.1 Active exceptions affecting NIST SP 800-171 R3 controls shall be documented in the POA&M and the SSP (forthcoming). During CMMC assessments, exceptions shall be presented to assessors with their compensating controls as evidence of risk management maturity.

4.7.2 The CTO/ISSM shall minimize the number of active exceptions affecting CMMC Level 2 practices prior to any C3PAO assessment.

5. Standards & Procedures Referenced¶

The following companion documents implement this policy:

Information Security Policy
Risk Management Policy
Exception Register — registers/exception-register.md (forthcoming)
POA&M Policy (forthcoming)
System Security Plan (forthcoming)

6. Compliance & Enforcement¶

Implementing a policy deviation without an approved exception constitutes a policy violation and shall be addressed per the originating policy's enforcement provisions. Failure to maintain compensating controls for an approved exception shall result in immediate revocation and may result in disciplinary action.

7. Exceptions¶

This policy does not permit exceptions to itself. All deviations from Aulendur security policies shall follow this process.

8. Definitions¶

Term	Definition
Exception	A temporary, time-bounded, approved deviation from a policy requirement, backed by compensating controls.
Waiver	A permanent or indefinite approved deviation from a policy requirement, backed by compensating controls and reviewed annually.
Compensating Control	An alternative security measure providing equivalent or comparable protection when a primary control cannot be implemented.
Exception Register	A structured record of all approved exceptions and waivers, their status, and compensating controls.
POA&M	Plan of Action and Milestones — a document identifying tasks to correct security deficiencies and reduce risk.

9. References¶

NIST SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
CMMC 2.0 Level 2, Cybersecurity Maturity Model Certification
DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting

10. Control Mappings¶

Framework	Control ID	Control Title	Coverage
NIST SP 800-53 R5	PM-10	Authorization Process	Supports
NIST SP 800-53 R5	CA-6	Authorization	Supports
NIST SP 800-53 R5	PM-9	Risk Management Strategy	Supports — exception risk management

11. Revision History¶

Version	Date	Author	Changes
1.0	TBD-YYYY-MM-DD	J. Gershenson	Initial issue.