SPRING DISCOUNT
Get 30% off on toolkits, course exams, and books.
Limited-time offer – ends May 26, 2022
Use promo code:
SPRING30

Expert Advice Community

Guest

Documents - Classification plan & storage for process documents like policies

  Quote
Guest
Guest user Created:   Feb 01, 2022 Last commented:   Feb 01, 2022

Documents - Classification plan & storage for process documents like policies

I'm trying to improve the document management for an IT department of an international food service company as part of my job. I'm a senior consultant on project management now. I've also been working as an IT architect and IT production consultant for years in the banking software development business. I've seen and done many useful things in the past but I've reached the limit of my knowledge in documentation management. I've never had to work on "policy documentation level" before as there always had been people in charge of that. I only had to use already written documents that were extracted from the documentation store for me by documentation or quality experts. I'm looking for small hints from an expert with a good information security view. I hope you can help me so I can move on since I'm a little stuck for the moment. Here is the context (part 1) : I've started writing an App Service management policy and reviewing the project management process a few months ago to stop the long and bad habit of my client's IT teams neither to write rules done nor update documents. At a moment I had to stop because I just had too much information and requirements to take into account. There are so many regulations, practices, and management systems to officially respect at the IT apps level for the company. My policy had started to look too much like a "cooking bible". I ended up wondering how to have people validate and keep live big documents. 1 - Here is the practice I've found (part 1) : After reading one of your article (https://advisera.com/27001academy/blog/2013/06/18/one-information-security-policy-or-several-policies/) I found that I just had to cut thinks in smaller pieces. Your article is also a nice argument since the architect manager had told me he prefers bible documents, and my manager doesn't like the idea at all. That article really is a great help for me. Thanks for writing it. You're the only expert to provide such information on policies organization. After reading an article from another expert  I've also decided to cut the documents per Management System and to respect an integration logic. Here are the systems to integrate at the document level I've already listed : QMS, SMS, ISMS, PMS, UMS, CMS, OHSMS, FSMS, EMS. I hope this is the good logic since your article is not covering the integration aspect of policy management. What's your opinion ? Here is the context (part 2) : I've also started wondering where to store the new documents so that the good people have the right access to read and update the right documents. With my manager we are working on "IT documents storage" improvement so that the documents can be made available to all the IT teams once written. For the moment there's also only procedures and operating modes, not policy in the storage. Documents are stored on a NAS that is not respecting the new IT tiered organization logic and that has been mixing BUILD & RUN documents for a very long time. The access also has to be changed to enable international IT teams to use documents originaly developed in France. Working on forms, procedures, specifications or projet documents management compliant with ISO 9001 standard is something I've already practice but the policy document management is really new for me. 2 - Here is where I'm stuck : For the moment I've found that documents storage should be organized with a classification plan that should reflect the processes logic. It sounds quite reasonable even if it is hard to visualize a sharepoint site design per processes. I've also found that policies are produced by pilot processes. So OK but policies are also used by operational managers as entry points when designing their own processes. From that on I'm stuck. How do classification plans manage the documents that are shared between processes owners ? I've not been able to find example of IT documentation storage yet to help me find the answer to that question or to find out if the "process logic" was the correct goal for IT processes document classification. Is there something about classification plans of processes documents in security standards ? Can you give me hints or advices so I can start writting a classification plan that can be used by sharepoint experts to build a nice & secured documentation site to host the old documents and the new policies ? Thanks.
0 0

Assign topic to the user

ISO 27001 DOCUMENTATION TOOLKIT

Step-by-step implementation for smaller companies.

ISO 27001 DOCUMENTATION TOOLKIT

Step-by-step implementation for smaller companies.

Expert
Rhand Leal Feb 01, 2022

1 - Here is the practice I've found (part 1) : After reading one of your article (https://advisera.com/27001academy/blog/2013/06/18/one-information-security-policy-or-several-policies/) I found that I just had to cut thinks in smaller pieces. Your article is also a nice argument since the architect manager had told me he prefers bible documents, and my manager doesn't like the idea at all. That article really is a great help for me. Thanks for writing it. You're the only expert to provide such information on policies organization. After reading an article from another expert  I've also decided to cut the documents per Management System and to respect an integration logic. Here are the systems to integrate at the document level I've already listed : QMS, SMS, ISMS, PMS, UMS, CMS, OHSMS, FSMS, EMS. I hope this is the good logic since your article is not covering the integration aspect of policy management. What's your opinion ?

Your logic is sound because you are separating the systems according to their core processes.

Regarding integration of policy management, ISO management systems have a lot of requirements in common, which allow using single documents with minor adjustments to cover core issues from several management systems (e.g., document and record control, internal audit, management review, corrective actions, etc.).

For further information, see:

Here is where I'm stuck : For the moment I've found that documents storage should be organized with a classification plan that should reflect the processes logic. It sounds quite reasonable even if it is hard to visualize a SharePoint site design per processes. I've also found that policies are produced by pilot processes. So OK but policies are also used by operational managers as entry points when designing their own processes. From that on I'm stuck. How do classification plans manage the documents that are shared between processes owners ? I've not been able to find example of IT documentation storage yet to help me find the answer to that question or to find out if the "process logic" was the correct goal for IT processes document classification. Is there something about classification plans of processes documents in security standards ? Can you give me hints or advice so I can start writing a classification plan that can be used by SharePoint experts to build a nice & secured documentation site to host the old documents and the new policies ? Thanks.

If I understood correctly, you are asking about access control management. ISO 27001 does not prescribe how to do that, only main guidelines on what you need to achieve, so you can use any logic that fits the organization's needs.  

Considering that, to build the structure you need to allow people to have access only to the documents they need to do their work, you should consider developing access control profiles according to required needs. In this case, you should:  

  1. list all documents that need to be accessed
  2. identify which roles/persons need to access each document, and with which rights
  3. group documents that have similar access requirements in profiles

As for roles/persons you can have, for example, developers, managers, architects, a specific person, etc. As for access rights you can have, for example, read access and edit access.

As for the idea of “process logic”, you can use them as a base for your profiles. Something like:

  • Pilot processes: roles/persons that need to develop/edit all documents
  • Pilot processes – step 1: roles/persons that need to develop/edit documents related to step 1
  • Pilot processes – step 2: roles/persons that need to develop/edit documents related to step 2
  • Pilot processes – step n: roles/persons that need to develop/edit documents related to step n
  • Operational processes: roles/persons that need only read access to all documents
  • Operational processes – step 1: roles/persons that need only read access to documents related to step 1
  • Operational processes – step 2: roles/persons that need only read access to documents related to step 2
  • Operational processes – step n: roles/persons that need only read access to documents related to step n

Since you’ve mentioned international access, you can further detail profiles by classifying them according to countries (e.g., Operational processes – step n – country m)

To see how this can be defined in terms of a policy, please take a look at this template: https://advisera.com/27001academy/documentation/access-control-policy/

For further information, see:

Quote
0 0

Comment as guest or Sign in

HTML tags are not allowed

Feb 01, 2022

Feb 01, 2022