RE: Policy-Procedure connectionBoth 17799 and ISO 9000 are actually process
apporach based model, However Please do not confuse the process approach with a
Engineering process - What ISO 9000 as basis and BS7799 advocate is a
Management Process Approach
So the Input in a management process is the Wish list of management from that
process and Output is quantification of that Wish list
Once you have outlined a process as above it becomes very clear for what you
wnt to do in the Process.. What ever activties along with Specific control
limits you want to set can become a part of the Procedures
These Procedures Ideally should be written with the involvement of concerned
People.One advantage is that people when involved will also follow the same
very easily without much convincing
In any case ,involvement of people is a good management principal
SAMPLE PROCEDURES....
Well all i let you know is what are the few characteristics of a GOOD PROCEDURE
1) It should be detailed
2) It should be easy to understand
3) It should speciy control limits if they are there in the procedure
4) It should be in the language that is understandable to the people
5) REMEMBER - They are meant for people who will USe Them
Manish Vig
Director
International Business
ICL Certifications Limited
----- Original Message -----
From: Garbellini, Kate (AU - Melbourne)
To: Sharon Steinbock
Cc: security-management@securityfocus.com
Sent: Tuesday, October 19, 2004 5:35 AM
Subject: RE: Policy-Procedure connection
Sharon,
It would be worth having a look at the ISO9001:2000 - Quality Management
standard if you can get access to it. Although it does not necessarily apply,
it provides more detailed guidelines around the roles and responsibilities for
process/procedures.
At a high level, it talks about the process owner being the closest person to
the process with authority to change it as required. The owner should then be
responsible for writing and initial approval of all process/procedures under
their control. Additional sign off authorities may need to be set, based on how
the process/procedure interacts with other areas.
I don't have any sample I can pass on due to confidentiality, however I
suggest that you make them as simple as possible. Some basic rules I always
follow are:
The process/procedure should include:
a.. Name
b.. Version Number
c.. Approval Date
d.. Scope: An explanation/reason, timelines and non-inclusions
e.. Roles & Responsibilities: The responsibilities of the
process/procedure owner, authorities and users.
f.. Process: This should include the triggers, a process flowchart and
where necessary (based on the skill level of the users) additional description
g.. Performance Measures
h.. Supporting Documentation.
Hope that helps,
Kate Garbellini
Director - Information Security
Enterprise Risk Services
Deloitte Touché Tohmatsu
505 Bourke Street
Melbourne VIC 3000
Direct: +61 (0) 3 9208 7029
Fax: +61 (0) 3 9208 7001
Mobile: +61 (0) 421 055 369
mailto:kgarbellini@deloitte.com.au
www.deloitte.com.au
-----Original Message-----
From: Sharon Steinbock [mailto:sharon@mimransteinbock.com]
Sent: Monday, 18 October 2004 6:07 PM
To: security-management@securityfocus.com
Subject: Policy-Procedure connection
Hello,
I am looking at implementing an ISO 17799 framework.
Getting the policies right is not an easy task, but I find the topic well
documented, with many sample policies I can use. However, when it comes down to
"translating" my policies to specific procedures I am lost. Some questions:
- Who should write each procedure? The procedure owner, his boss, someone
higher up?
- Where can I find some sample procedures?
Any other insight regarding the policy-procedure gap will be highly
appreciated.
Thanks,
Sharon
***********Confidentiality/Limited Liability Statement***************
This message contains privileged and confidential information intended
only for the use of the addressee named above. If you are not the
intended recipient of this message, you must not disseminate, copy or
take any action in reliance on it. If you have received this message
in error, please notify Deloitte immediately. Any views expressed in this
message are those of the individual sender, except where the sender
specifically states them to be the views of Deloitte.
The liability of Deloitte, is limited by, and to the
extent of, the Accountants' Scheme under the Professional Standards
Act 1994 (NSW).
The sender cannot guarantee that this email or any attachment to it
is free of computer viruses or other conditions which may damage or
interfere with data, hardware or software with which it might be used.
It is sent on the strict condition that the user carries out and relies
on its own procedures for ensuring that its use will not interfere with
the recipients systems and the recipient assumes all risk of use and
absolves the sender of all responsibility for any consequence of its use.
