Your policy should probably not just say "you CAN NOT do this period"
and leave everyone wondering what should be done in this case or in that
case...
While thinking about your policy ,you should consider not just the risks
you are trying to mitigate ("let's forbid that because it is
dangerous..."), but also what may be needed in regard to doing business
that you are going to disturb if you forbid something completely ("we
can not forbid that completely because X will not be able to perform Y
and they may need to!").
You will than have to say in the policy "general policy is that you CAN
NOT do this, unless you ...." and than point to procedures that cover
the areas where you expect to have requests for policy "exceptions".
Each procedure should than have an owner (the person that will
approve\disapprove the request - he should be familiar with the relevant
domain), and will include the form for the request, and the criteria
that will be used when evaluating the request.
If you provide an example of a specific area that gives you grief, the
discussion can get more focused.
-----Original Message-----
From: Non Proprio [mailto:non@synaxis.org]
Sent: ה 28 אוקטובר 2004 15:34
To: security-management@securityfocus.com
Subject: Security policy exceptions template?
After years of whining, crying, shouting, etc., we have at least a
skeletal, enterprise security policy.
Now the question is how to approve and document exceptions to the
policy. There is no formal change control or management framework for
software (I know ... ugh).
I have all the Cresson Wood materials, 17799, CoBiT, etc. so what I'm
really looking for is a CYA I guess, but I also want to do what's best
for my company given the relatively crude maturity level of internal
processes.
