How to document ISO procedures

[Jacob-Jan van der Spek]

Our case description:

we're a software company of around 200 employees, working on getting ISO 27001 implemented. We're struggling with how to document / implement this in our Confluence instance.

Our current situation is that we have spaces for various departments (ie: Sales, administration, Customer Support, R&D). Each space has the possibility to add procedures (with a predefined template).

As procedures can be relevant for multiple for multiple departments (ie: order processing is relevant for sales & administration), we use labels combined with the content by label macro to show a procedure over multiple spaces. However: as the correct labels have to be added manually, this probably will be forgotten when creating a new procedure.

So my question: how do you guys do this, we've been thinking about some alternatives:

• all procedures set in one 'procedure space'
  The procedures aren't really embedded in the workflow of the employees
  Managing all procedures will probably be easier.
  Searching for a procedure will probably be easier.
• Procedures are cut up into pieces (the order processing procedure will be split in 2 parts, one for sales, one for administration, with (for instance) a link at the end of the page, or a 'dependencies' block at the top of the page.
  I expect it will be harder to manage all procedures in this case.

I'm very curious for your replies!

[LaWaune Netter]

Jacob, did you find a solution?

[Maciej]

I would also be interested to know that.

[Blake Hodder]

I am also interested in this. Trying to tie JIRA and Confluence together for ISO.

[Jacob-Jan van der Spek]

Hi there.

Unfortunately not yet. The project has also changed ownership. I'll inform the new owner on this topic.

[Blake Hodder]

Thanks.

Much appreciated.

[Thomas Ohrbom]

Hi, we have opted to go for alternative 1, ie. having all governing documents in one management system space. By governing documents we mean the following "levels" of documents from top to bottom:

• policies
• guidelines
• procedures (visual process descriptions and textual procedures)
• work instructions
• customer specific SOPs

All governing documents have labels indicating the type of document (policy, procedure etc), and primary target audience (typically companies and/or departments).

Each department also has their own department space. Some departments have opted to setup a page in their own space which will list the governing documents relevant for that department, using the Content By Label macro.

An added "bonus" is that with this setup we can enforce one common approval process for all revisions of governing documents more easily, as we only need to control one space.

[Sharon Meyler]

HI Thomas. What "common approval process" did you use? I am experimenting with the Page Approval macro but I am not impressed so far.

[Thomas Ohrbom]

@Sharon Meyler I have to admit we are currently using a manual approval process using two spaces:

• The Management System space
  • All users have read access
  • Process owners have write access - for revising existing governing docs
  • Two admins (myself included) watch the space and review any changes, and "approve" by updating the metadata (page properties macro and labels). We also "clean up" the version history if the author has published several new versions (single typos etc).
• A draft space for new governing docs
  • All users have read and write access
  • Anyone can draft and propose new governing docs
  • Once a draft is ready for review and possible publishing I am contacted
  • Review is performed with the relevant process owner(s)
  • If approved the new governing doc is moved to the Management System space

Currently there is little activity and few process owners actively revising documents, so this is manageable. 

We are considering using either Scroll Documents for Confluence (which has a lot of other functionality we are interested in) and Comala Approvals (basic) or Comala Workflows Lite.

[Sharon Meyler]

Thanks for the reply, Thomas. What you are doing makes sense, but as you say, it is manual. I'll check out the Comala - Page Approval doesn't really seem to be of much benefit.

[Thomas Ohrbom]

I think the Comala Workflows Lite is the better choice. More functionality than the Approvals, and just marginally more expensive.

[Shannon Meehan (K15t)]

Hey @Thomas Ohrbom , it's great to hear that you're considering Scroll Documents for this. I actually work on the Scroll Documents team here at K15t and we just released an Activity Log feature that can help when it comes to tracking and reviewing changes and even approvals. 

There are more details in the documentation, but essentially you can track any changes to a document and all of its pages from one place. The log shows you when a workflow status was changed, when the document was approved and by which user.

You can also see when versions were saved and drill down to see which individual pages of the document were updated and who made changes between versions. 

If you have any questions, we'd be happy to help or show you a demo of the app. Just get in touch with us: hello@k15t.com.

Cheers, Shannon (K15t)

[Maurice Pasman]

Check out https://instant27001.com/, its a ready-to-run ISMS based on Confluence, that contains all the content you will ever need, no plugins required.

[Iz P]

@Thomas Ohrbom you said 'We also "clean up" the version history if the author has published several new versions (single typos etc).' I'm wondering how you do that? I have a problem with extensive versioning - every little change is a new version (so I should make approvement, inform stakeholders etc.). I doesn't make sense. I am thinking about manual marking version if there is any significant change and don't use the verb version for documentation control.