Documentation is just as important as correctly securing a
technology, without it the details can stay inside peoples heads, which can
lead to it being forgotten or easily leaving an organisation. Let’s look at how to do it, so it is both useful
and meets our compliance or regulatory requirements.
Before looking any further it is important to understand the
different types of documentation, so you can understand what a standard such as
PCI DSS is actually requires from you:
Policy: Policy is
management’s way to direct staff to do something, or to set expectations for
something such as a certain level of control.
An information security policy is the starting point of an organisations
commitment to managing security risks.
Procedure: A
procedure is defined as a detailed description of the steps necessary to
perform specific operation. To take this
further a procedure is how you as a business are going to implement the desired
level of control. This can be seen as
the business response to the management objective set in a policy. A procedure can also be the operation of a
specific control. In some cases a
specific procedure to detail the correct way a set of actions should be
performed.
Standard: A
standard is a set of rules or specifications that, when implemented together
define a software or hardware asset. The
make it compliant blog has already completed a guide on defining configuration
standards; this forms a really good basis for a standards document (but I may
be biasedJ). A key point to note with standards is there
should be a defined exception handling and authorisation process; because we
all know that it is not always possible to implement every detail all the
time.
Guidelines: These are suggested actions or
recommendations related to an area of a policy that may supplement a
procedure. Unlike a standard,
implementation of guidelines may be at the reader’s discretion. For example a policy statement may state that
employees are required to wear identification at all times, a guideline may
outline that the acceptable wearing is either on a neck tie or a pass holder;
often directing the user where to request or find supplies of these.
Form: A policy
may state a requirement for records to be maintained of control implementation,
the best way to record this is through the completion of a form. A procedure would define the level of detail
required to be completed within a form and the required management
authorisations to be captured. Forms can
be paper based or electronic, but they are useless if they are not maintained.
Presenting an auditor or assessor with a good set of
structured documentation is an excellent way to start presenting your business
as meeting the spirit and intent of many compliance and certification
requirements. If your documentation is a
mess, one’s first impression is that your environment is going to reflect this.
Some believe that having a 100 page policy document is not a
good move, and some will argue if it is the one source of information people
always know where to look. I think that
this is never going to be resolved, especially here. The truth is it doesn’t really matter as long
as the target audience can navigate it and understand it, and the key to this
is referencing.
A policy document should identify supporting procedure
documentation when required; a procedure should identify the applicable
standards, and so on. If you have a 100
page policy document you should reference procedures as you go. If you have independent documentation, then
these can be referenced at the end.
Assigning an owner to a document is a requirement to show
that controls are owned, this creates accountability within the business. Controls are only ever implemented when people
are informed and aware of their responsibilities.. This is why hierarchy is important in
documentation, and assignment of responsibilities starts at the executive
level, tone at the top is important to ensure that staff at all levels
understand the business requirements, especially for security. A simple responsibilities matrix across the
documentation of a business can be an excellent tool to help capture and define
accountability and responsibility.
Make it clear who the target audience for the document is,
make sure it is available to them, they know where to find it and can reference
it easily. Making documentation that is
applicable to the staff and can be maintained by them is important. Documentation for compliance is not a one off
exercise; it must be demonstrably maintained during the year.
Documentation should also identify the expected frequency of
the control’s operation and associated reporting criteria. The reporting criteria should include metrics
that allow the effectiveness of the control(s) to be measured. Having good management information about
compliance before assessments ensures that there are no surprises. If there has been notification about control
failure or a noted issue, management can prepare a response.
Management of exceptions is especially important when dealing
with a control based assessment such as PCI DSS, if a control is not in place
non-compliance must be noted. The PCI
DSS allows for compensating controls to be noted to assist in areas of non-compliance;
however these are not just documentation. The compensating controls should
produce evidence to show that you have been managing the risk, and will
continue to do so once the assessment has finished.
Documentation should also identify where management
information on controls are reported.
Not all information is required at Executive level. To ensure effective
sponsorship and engagement in information security only relevant information
should be provided. Control failure
tolerances should be defined this too can impact on reporting lines. Some people only need to know about failure. The most important part is that someone knows
and is taking the necessary action. This
is the control owners’ responsibility to delegate, either to individual
functions or the governance structures of a business, such as a security
committee or risk committee.
No comments:
Post a Comment