Policies: Defining the "Why" Behind the "What"
      Back to home
      1. Trustero Support
      2. Phase 2: Formalize Policies & Supporting Documents
      3. Policies: Defining the "Why" Behind the "What"

      Managing Policy Deviations (“Exceptions”)

      An explanation of exceptions, plus best practices to formally manage and document them

      What is an exception? 

      In the realm of information security, an exception is a formally documented acknowledgment that an element of your InfoSec program is not in line with established policies, standards, or practices. There are a variety of reasons why a company might need to make such an exception, ranging from technical constraints to business necessities, or other considered risk-based decisions.

      Key Points About Exceptions

      • Deviation from Policy
        An exception is recognized when practices deviate from set security policies or controls.
      • Risk Assessment
        Each exception should come with a risk assessment to gauge the potential impact and likelihood of associated security risks.
      • Management Approval
        An exception requires approval from management, which means the risks are recognized and accepted at the correct organizational level.
      • Mitigation Strategies
        Documentation should detail any additional controls or strategies implemented to manage the risk at an acceptable level.
      • Review and Expiration
        Exceptions are not permanent fixes. They need regular reviews and have a set expiration date, necessitating re-evaluation or resolution of the compliance gap.
      • Documentation and Tracking
        Keeping records of exceptions and their approvals is essential for maintaining an audit trail and clear visibility of the company's risk posture.

      💡 Dispelling a Common Myth: 

      It's important to note that having exceptions documented does not mean your organization will automatically face negative repercussions in an official Audit Report or Certification—such as a SOC 2 Report. Auditors understand that deviations occur and that risk is a part of doing business. What's crucial is your organization's ability to detect, assess, and manage that risk effectively. 

      Practical Examples

      • Bring Your Own Device and Technology (BYODT) Agreement
        • Situation: Sam, who is part of the leadership team, owns their laptop and has requested an exemption from connecting to the mobile device management system, since they use the laptop for personal purposes.
        • Mitigation: To address the risk, Sam has signed a BYODT Agreement to ensure they understand and comply with the security requirements, as defined within the policy.
        • Recommended Action: Document the signed BYODT Agreement as evidence for the device exemption and upload to the control. Add a comment under “Add Evidence > Display Text” explaining the business justification and risk mitigation in place.

      Example comment: “User has signed a BYODT Agreement outlining acceptable use and security protocols. Device access is limited to email and is protected via company-enforced MFA.”

        • Outcome: This approach acknowledges the policy deviation while showing proactive risk mitigation. It helps auditors understand the control is intentionally scoped with safeguards in place.
      • Background Check Exception
        • Situation: Jordan transitioned from a contractor to a full-time employee (FTE) and did not undergo a complete background check typically required for new hires.
        • Mitigation: To mitigate any potential risk from this exception, Pat, a senior member of the team, vouched for Jordan based on his prior work and reputation.
        • Recommended Action: Record the exception in a centralized exception log or evidence repository, including the rationale and responsible approver. In Trustero, add supporting documentation or a note in “Add Evidence > Display Text” under the relevant control.

      Example comment: “Jordan transitioned from a contractor role and was previously vetted. Formal background check was deferred with manager approval. This has been logged and will be reassessed during next review cycle.”

        • Outcome: This demonstrates that the organization acknowledged the risk, documented the rationale, and applied a reasonable level of oversight - all key audit readiness indicators.
      • AWS Root Account Exception (IAM01 – Unique User IDs)
        • Situation: Your AWS environment includes the root user in the IAM user list, which causes the Trustero AI Control Check for IAM01 (Unique User IDs) to flag it. This is correct — root is not a unique user and should not be used regularly.
        • Why This Is OK (If Managed): The presence of a root user is acceptable if the organization documents compensating controls and limited usage.
        • Recommended Action: 
            • Do not exclude the root user via the Receptor. This can cause integrity issues during audits.
            • Instead, go to “Add Evidence > Display Text” for the flagged control and include a comment such as:

      “The AWS root user is restricted to emergency-only usage. It is protected by MFA and accessible to only two administrators. CloudTrail logging and alerting are enabled to monitor any login attempts. The account is reviewed quarterly to ensure it remains unused and secured.”

        • Outcome: This comment helps both auditors and the AI Control Check understand that the risk is known, managed, and mitigated - turning a potential red flag into a documented, compliant exception.

      Conclusion

      Exceptions are a natural part of managing an information security program and do not inherently signal a lapse in security. Instead, they are indicators of a responsive and adaptive security posture that accommodates the organization's operational needs while maintaining oversight and control over security risks. 

      For more information or guidance on handling exceptions within your InfoSec program, please reach out to our support team or consult our comprehensive resources.