As with so much in what we do, "It depends". I've recently moved to a new
industry (pharma) where policies are treated as absolutes. If you can't
meet a policy requirement, you better have a policy exception in hand.
Problem is, exceptions breed other issues and if everyone needs an
exception, why do you have that policy?

So a part of the equation is understanding your compliance environment. How
does Internal Audit handle policy audits? Do external auditors or
regulators care about your policies?

Next up is how you write your policy. Many organizations have a particular
format or even a syntax to the structure of a policy; others don't. You
will have to make yours fit that approach.

I like to write an overarching policy statement that describes the intent,
scope, and responsible people (by role) associated with the policy. Under
that, you write the actual responsibilities for the policy. I write those
as control statements. A responsibility is a control if the answer to the
question, "Is this being followed?" can only be "Yes" or "No". "Sometimes"
equals "No". If you have a control that says, "Email shall be maintained in
accord with the retention schedule.", then optionality is not possible. You
can argue that you treat your employees as adults and expect them to follow
the retention schedule, but if you have a further statement somewhere else
that demands consistency, you're going to have a problem. In any event, if
users can decide when they get rid of records (and which ones they get rid
of), the control likely fails somewhere. And an auditor will write that as
a finding. Sometimes policies have contained statements like, "Fewer
records are better than more records." That's not a control. It might be
true, but it is not a control statement.

In the InfoSec world, a control would be: "Passwords must contain a minimum
of 12 characters, with three levels of complexity, one of which must be an
alphabetical character." (You define "complexity" elsewhere, but it means
1) capital letters, 2) small letters, 3) numbers, 4) acceptable symbols.) A
control would not be, "Longer passwords are better than shorter passwords."
Again, that's true, but not a control. There's a further problem with that
control, however, because certain types of devices may not comply.
Smartphones, for example, may require only a number PIN or use a biometric
(fingerprint). So that set of controls have to be taken back to a point
where you establish a foundation for identify and access management, then
define controls specific to certain classes of devices or applications, or
users.

Similarly, you have to build some foundations for records and work your way
through your controls. The foundations are called frameworks or
architectures and are often based upon industry standards. That may mean
building a structure that looks like the Generally Acceptable Recordkeeping
Principles. It could mean following ISO15489 (or the related ISO standards
-- https://www.iso.org/committee/48856/x/catalogue/). You likely have other
regulatory requirements.


After controls, you write procedures. The procedure is the "how to" aspect
of the control. This is how you meet the control. In my case, these carry
some weight, but there can be alternate ways to meet the control. That
doesn't mean that every control has a procedure, but its not uncommon for a
particular control to have multiple procedures in order to meet geographic
requirements, system differences, or particular regulatory requirements
(SOx versus non-SOx systems). And again, your audit / compliance
environment will dictate how you write these as well. Some auditors will
consider procedures to have the force of policy, rather than being guidance.

In some organizations, audit findings are seen as good because it allows
you to have a stick to beat funding out of the organization. In others, a
finding is failure to comply and the stick is used to beat the responsible
party -- and in turn, the responsible party comes looking for the person
who wrote the policy that they couldn't comply with.

So that part goes to whether or not your organization sees policy as
absolutes or aspirational. If the former, you may want to limit yourself to
control statements that are mostly able to be met, with a long view of
implementing more stringent controls. So maybe you start with where
information is maintained, and how it is organized and implement retention
requirements when that can be automated. If the policies are more
aspirational in design, then perhaps you plug everything in, with an
expectation that you'll move in the direction of full compliance over time.

I think for too long many of us have written the "Thou shalt maintain thy
records in accord with the retention schedule!" types of policies, then
thrown up our hands when someone wants to know exactly how that applies to
a database or 4 gigabytes of email. It's not a winning approach and if not
enforced, has little value and is ignored.

Patrick Cunningham, CISM, FAI

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]