3 hours 54 minutes

Video Description

In this lesson, we will look at exceptions in the realm of policy management. While policies are intended to be inclusive, there will be situations where exceptions to that policy will be required. Whether it's hardware that cannot be brought into compliance or staff who necessarily must be exempted; there must be a procedure set up to deal with the inevitable exceptions to policy. The Process of Managing Exceptions The procedure for how exception requests are submitted, evaluated and documented must be documented. An exception request form should be customized and standardized, and consequently used as a template. There must be a concomitant response form that will be completed by the individual who approves or rejects the exception request, and a tracking log should be kept of all exceptions that have been granted. There are supplementary documents that should be included in the exception process: - Descriptions of roles and responsibilities - Technology standards - Workflows demonstrating how security functions performed by different departments combine to ensure secure data handling Guidelines that advise on the easiest ways to comply with security policy.

Video Transcription

Okay. Now, we've mentioned earlier that polishing policies should be inclusive and within the policy. We're not gonna list out and say this policy applies to everyone except blah, blah, blah. We're gonna have an inclusive policy. But we also have to acknowledge the fact that there will be exceptions to policies.
We may have systems that
technologically speaking or able to be brought into compliance, maybe their legacy systems. We may have certain staff that in policy doesn't apply because of maybe they're located down the field. You know, whatever those exceptions are,
we write policy, and then we create exception documents.
So these air elements where we make those, uh, exceptions based on special circumstances, Maybe this is a temporary postponement of being in compliance, whatever that may be. But there needs to be a formalized process in relation to handling exceptions
because policy should be universe
aren't so. If we talk about managing acceptance exceptions, we're gonna document the procedures for how exception requests are submitted, evaluated and documented. We should have a standardized form to submit for an exception request that should be evaluated by a certain party.
And then the results of that should be documented.
We're going to create that customized on customize an exception request form. It needs to be available as a template.
Ah, did. We're gonna decide who the individual is. That's gonna prove a reject. The exception. And then we're gonna document in a tracking log. So, for instance, this is an example of what we might uses as an exception request for so you can see who's requesting when they're requesting it.
As for as you know, which policy
are you looking to accept from and what system? What are the reasons? Ah, what are you looking to do? What would the impact me if this were a policy were to be applied to the system or if it wouldn't. And again, this isn't a mandatory.
These aren't made toward fields on your exception. Request form
the form that you creates really gonna be driven by your business. But ultimately you can see what we're really looking for is who's submitting their requests. Why? What's the anticipated of impact if we don't implement policy on the system versus if we do
now, from there, the reviewers gonna have an exception response for so I, as the reviewer and gonna document and say, Look, here's the decision that we've made We've We've allowed this exception. We've denied this exception any sort of criteria.
If we are allowing an exception, does that exception terminate?
So ultimately, again, we're filling out the information. So it's very clear whether or not the exceptions been granted or denied And then any sort of logic behind that decision,
all right, And then we have attractive. All this is really done. Best online, a CZ. Most of this is Thio s so that you can organize this information effectively. So fields like you know what the exception number is so that we can categorize are exceptions.
When they were, the exception was requested,
whether it was denied by whom any sort of dates involved any sort of comments. So ultimately, this is gonna give us the ability so that we can go back. If we find a group of systems that are not in compliance with policy and go back and check that tracking log and see oh, they were granted an exception.
And that exception is good through the beginning of the year or the end of third quarter, whatever that month,
and then we'll also have any additional supplementary documents that will be part of our policy. Maybe we have a standard document that details roles and responsibilities, specifically individual roles in the organization. What they're responsible for,
uh, any sort of standards,
any sort of baseline configuration documents. Um
ah, configuration requirements would sort of put processes. We haven't placed any sort of guidelines. But ultimately, part of policy is to reference those other documents that are relevant. So whether it's industry standards, whether it's to be in compliance with standard operating procedure, best practices,
what are the works, learns that we have.
All of that information could be included in the supplementary documents.

Up Next

Chief Information Security Officer (CISO)

In this CISO certification training, you will learn what other CISO's are focusing their time and attention on. Among the key topics, you will learn how to implement the proven best practices that make for successful cyber security leadership.

Instructed By

Instructor Profile Image
Kelly Handerhan
Senior Instructor