Roles & Responsibilities in Policy

Risk Assessments almost always produce one finding consistently.  The finding is lack of roles and responsibilities defined.  The ISO 17799/27001 documents provide some guidance, but in many cases organizations do not know how to define clear security roles and responsibilities.  Before writing this I went through about 20 different organization policy documents to see if any listed roles and responsibilities the same.  In most cases I noticed three solutions.

Solution 1:

This solution did not include clearly define roles and responsibilities.  These documents contained few responsibility statements that were scattered through all different areas of the main security policy or policies.

Solution 2:

Solution 2 was the most consistent across all documents reviewed.  This solution usually defined three specific roles and responsibilities.  These are information owner, information custodian, and information user.  Each of these three roles had several statements defining their responsibilities, while there were additional statements scattered through all different sections of the policy document.

Solution 3:

Solution 3 was more consistent on policy documents that are broken up into smaller documents or much shorter in overall length.  This solution usually had specific roles such as Firewall Administrator, CSO, System Administrators, Compliance Officer, Audit, etc.  In most cases each of these roles had several bulleted responsibilities listed.

What Works?

The best solution is the one that works within your organization and causes less confusion.  If risk assessments are performed regularly then make sure the roles and responsibilities are written address the risk assessment requirements.  Two methods usually work.    

The first is to combine solution 2 and 3 and write a separate roles and responsibilities document or section of the overall policy.  This way there are many roles and responsibilities defined, which are easy to find because they are listed all in one place.

The second is to use solution 2 near the beginning (or in a separate policy document) of the policy document then in each different section of the policy (or each smaller policy document) write a roles and responsibilities sub section with more detailed roles.



  1. Another method that I have seen work is the elaboration of security roles & responsibilities (r&rs) within the supporting IT and security specific processes/procedures. My own approach to documenting security frameworks is to keep the policies as concise as possible, with further documentation used to elaborate on the details (where appropriate and necessary).

    However, I also tend to pull the high level r&rs into an overall r&rs document. Avoiding duplication is an useful objective to have. Quite often I work with tools that allow easier cross referencing, importation of content, etc to help manage this. However, even if duplication isn’t avoided, I think it can add benefit: having a single point of reference for this information can help with the framework development and, of course, with auditing (internal and external).

    But, as you pointed out: the best solution is the one that works for $you.

  2. Great feedback Dave! Avoiding duplication is always an important part of policy development. Can you share some of the tools that you use?

  3. I think a blended approach works best. But what I like to see are:
    1) Some high level requirements for information owners/custodians/etc outlined in the infosec policy doc.
    2) Then in the job descriptions maintained by HR there should be specific security requirements for every position, from Board members down to the janitor. These need to be acknowleged by the employee (black ink on dead trees or equivalent).
    3) Requirements for information security compliance documented and acknowledged in contracts with third parties.

    The requirements for 2 & 3 should be outlined in the infosec policy.


  4. Sure, but you will be decidedly unimpressed 🙂

    Web based delivery is popular these days and for me it’s the preferred method of content delivery. Even a simple HTML document structure can lend itself to useful cross referencing. Throw in a data store, some software development or an off the shelf (OTS) package (free, beer, dinero, whatever) and you’ve got yourself a more flexible beast. I’ve made use of trac (a wiki) in the past for delivering the documentation aspects of security frameworks. Many people hate them (wiki’s), but like all things: you use what is suitable to your environment. The wiki approach has worked pretty well and trac (esp. if you’re familiar with python) can be a quite flexible tool for online collaboration and information publishing. I even extended the ticketing system to provide some basic workflow functions simple incident management functions and other processes reduced to ticket driven activites. Not perfect, but it was a good fit (low budget) for the requirements we had at the time and I’ve found it useful in other situations since. Once you have a datastore, it becomes possible to tag and reference data stored, which then facilitates importation, cross-referencing, etc.

    I’m sure you could get similar mileage from the myriad content management systems (for those who would rather not get their hands dirty).

    Dare I mention it, but it is possible to do this with our favourite word processing tool. With a bit of work and a lot of patience (it’s those idiosynchracies that make it worth the effort!), you can have nice referencing and some clunky content importation (via {IncludeText} for example). With a bit of coding, you can make this much more complicated than it needs to be and get further results 😉 Newer XML format make this a bit easier.

    As you can probably tell, my previous budgets for documentaiton management and content publishing were not astronomical. Recently, I’ve observed some COTS documentation management solutions and they appear to achieve the same results, whilst offering contractual appeasments to those who need them. Only observations: I’ve not had to work with them for a prolonged period, and, as such, would not make a recommendation (or advertisement) for/or against any of these products.

    Caveat emptor: both in the technology chosen and in the style/methodology adopted by the organisation.

    Perhaps the most important tools for avoiding uneccessary duplication are good (!) planning and controlling the documentation process (drafting, updates, peer reviews, approavals, etc). Systems can help solve problems, but (thankfully) they still require a little bit of human direction 😉

    “Documentation is a process, not a solution” … eh?

  5. El Pato!, I agree with you. Job descriptions and yearly planning exercises are a useful for capturing obligations and objectives for personnel. These are controls within themselves and are rightly referenced in the best practice security literature (e.g. ISO 17799).

  6. I do not drop a bunch of remarks, however I read some of the remarks on this page Roles & Responsibilities in Policy | InfoSecAlways.
    com. I do have a few questions for you if it’s allright. Could it be simply me or do a few of the remarks look like they are written by brain dead people? 😛 And, if you are writing at additional sites, I’d like to keep up with everything fresh
    you have to post. Could you make a list of every one of your social community pages like
    your Facebook page, twitter feed, or linkedin profile?

  7. Hi, i feel that i noticed you visited my website thus i came to return the favor?
    .I am trying to find issues to improve my site!I suppose its good enough to make use of some of
    your concepts!!

  8. Heya i am for the primary time here. I found this board and I find It really useful
    & it helped me out much. I hope to give something back and aid others like
    you aided me.

  9. You are so cool! I don’t think I’ve truly read
    through a single thing like this before. So great to find somebody with
    a few original thoughts on this topic. Really.. thank you
    for starting this up. This website is one thing
    that is needed on the web, someone with a little originality!

  10. Undeniably believe that which you said. Your favorite reason seemed to be on the internet the
    simplest thing to be aware of. I say to you, I definitely
    get annoyed while people think about worries that they plainly
    do not know about. You managed to hit the nail upon the top and defined out the whole thing without having
    side effect , people could take a signal. Will likely be back
    to get more. Thanks

  11. It’s a shame you don’t have a donate button! I’d without a doubt donate to
    this superb blog! I guess for now i’ll settle for bookmarking and adding your
    RSS feed to my Google account. I look forward to fresh updates
    and will share this blog with my Facebook group. Talk soon!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s