Option to mark "FAILED" results as "ACCEPTED RISK" #1215
XTRM-Dev-Mark
started this conversation in
Ideas
Replies: 1 comment
-
|
I, too, have a number of these, that because of our business activities etc we have gone a slightly different path. One thought, i think “Risk Accepted” sounds better.. If it created an extra folder in Maester so it doesn't nuke them when we update the tests would be helpful. Not sure what you would do for updates because if the tests change they are going to have to allow for this in the code?, but im not a coder.. It would also be nice if we had a Risk Accepted category on the results page so we can review them. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I’d like to suggest an improvement to how test results are handled.
Current behavior:
Automated tests return a binary result: PASSED or FAILED.
If something has FAILED, it always shows up as non-compliant, regardless of organizational context. And will keep showing as FAILED in each run. Current work around is to exclude that specific test item, but then reports are not 100% complete.
Issue:
In some cases, organizations intentionally accept a deviation after internal risk assessment or policy decisions. For example:
Allowing more Global Admin accounts than the recommended baseline.
Keeping a certain configuration that violates the best practice but is a deliberate exception.
Right now, these appear as strict FAILED results, which doesn’t differentiate between real issues and accepted exceptions.
Suggested improvement:
When a test result has FAILED, provide admins the option to mark it as “ACCEPTED RISK”.
Require a short justification when marking it this way.
From that point forward, the result would show as Non-Compliant (Accepted Risk) instead of a plain FAILED.
This status remains until an admin explicitly “releases” that test item again (removes the exception).
Benefits:
Keeps reporting accurate and transparent.
Differentiates between issues that need fixing and exceptions that are accepted.
Supports auditability: exceptions are still visible but clearly documented.
Beta Was this translation helpful? Give feedback.
All reactions