Get 2 Documentation Toolkits for the price of 1
Limited-time offer – ends March 28, 2024

Expert Advice Community

Register of Requirements — how detailed should it get?

  Quote
Scott D Created:   Aug 17, 2021 Last commented:   Aug 24, 2021

Register of Requirements — how detailed should it get?

Hi, I'm using Confirmio to build out our ISMS and I'm on the Register of Requirements step. I'm trying to get a sense of the downstream impacts of being too detailed (or not detailed enough) here, and whether or not to be aspirational (i.e. list things we're not compliant with yet) or leave them out. Some examples: - A single contract could provide dozens of clauses that each map to a different area within cybersecurity (e.g. privacy, data breach reporting, operational security, secure software design, service level agreements, etc). Do I break down the contract terms into chunks? Or do I add just the contract as a single record? - There are some government policies in place that apply to our customers but not directly to us. It obliges them to implement contractual terms and controls on us, and in some cases they haven't yet this done. So in a strict sense we're not on the hook for these yet, but I'd like to plan to become compliant over time anyway. Do I add them and check non-compliant? So my questions are really two-fold: First, what is the downstream impact of adding these items? Is it more onerous to then complete the ISMS set-up with more items here? Is simpler better? What do auditors expect? And second, what is the impact on having items in this register in a "non-compliant" status as it applies to certification? Does everything need to be green within these registers before we can be certified, or is a working system with non-compliance being tracked of greater interest to an auditor? I'm interested to hear what's worked for others in the real world who've achieved compliance. We're only a small team. Thanks in advance!

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 Aug 18, 2021

1 - A single contract could provide dozens of clauses that each map to a different area within cybersecurity (e.g., privacy, data breach reporting, operational security, secure software design, service level agreements, etc.). Do I break down the contract terms into chunks? Or do I add just the contract as a single record?

The way of handling this situation will depend on who will be responsible for fulfilling the requirements. If a single role will be responsible for all requirements, then you can include a single register. In case the specific requirements are to be treated by different roles, that it is better to split the requirements into different records.

2 - There are some government policies in place that apply to our customers but not directly to us. It obliges them to implement contractual terms and controls on us, and in some cases they haven't yet this done. So, in a strict sense we're not on the hook for these yet, but I'd like to plan to become compliant over time anyway. Do I add them and check non-compliant?

You can add such requirements and define a deadline for compliance in date as far away as possible (e.g., up to 2 or 3 years from now), so you can have the situation mapped in your ISMS but you are not obliged to implement them any time soon.

3 -  So, my questions are really two-fold:

First, what is the downstream impact of adding these items? Is it more onerous to then complete the ISMS set-up with more items here? Is simpler better? What do auditors expect?

Adding requirements after implementation is always more onerous than during its initial implementation because at first implementation you will have a more complete picture of what needs to be implemented and adjust your implementation accordingly in case some requirements are to be implemented later (e.g., you can leave processes and documents ready to receive and work with these later to be implemented requirements).

In terms of auditors, what they expect is that requirements stated as fulfilled by the time of certification audit are properly covered by the ISMS processes, policies, procedures, and controls.

4 - And second, what is the impact on having items in this register in a "non-compliant" status as it applies to certification? Does everything need to be green within these registers before we can be certified, or is a working system with non-compliance being tracked of greater interest to an auditor?

I'm interested to hear what's worked for others in the real world who've achieved compliance. We're only a small team.

Thanks in advance!

For certification purposes, you must not have requirements not treated (this will prevent the audit to proceed). In case you have this situation, you have two alternatives:

  1. Postpone the deadline for fulfilling the requirements (so they are irrelevant for certification purposes)
  2. Identify all risks related to these requirements as acceptable (so you will not need to implement any controls)

Please note that for both situations you need to evaluate the impact on the business.

Quote
0 1
Scott D Aug 19, 2021

Thanks Rhand, nice and clear advice.

I'll give that a go.

Quote
0 0
Kevin Foley Aug 19, 2021

I am a similar situation..

Multiple customers with the same cybersecurity requirements.

Would I just add one register entry that looks like

  • Requirement type: Contractual
  • Name of party: All banking customers
  • Stipulating document: All customer contracts 
  • Requirement Description: Implement cybersecurity requirements
  • Area requirement related: Other ?

We already implement these cybersecurity requirements.

Would the details for these "cybersecurity requirements" be chosen in the Statement of Applicabiltiy regardless of what was put in the register?

 

Quote
0 0
Expert
Rhand Leal Aug 24, 2021

Please note that the "cybersecurity requirements" to be included in the register are those defined in the customer contracts (e.g., data backup, need for data segregation, right to audit, etc.). You can either write the requirements in the register or only refer to contract clauses.

The link between the legal register and the Statement of Applicability will be the ISO 27001 Annex A controls applied to fulfill the contractual requirements. For example:

  • data backup: A.12.3.1 Information backup
  • need for data segregation: A.13.1.3 Segregation in networks
  • right to audit: A.12.7.1 Information systems audit controls

In Conformio this is performed during risk assessment and treatment when you identify relevant risks of legal requirements compromise and define the necessary controls to be applied for risk treatment (these will be displayed in the SoA).

Additionally, once security policies and procedures are being written, Conformio reminds users about the relevant requirements from the Register of Requirements.

Quote
0 0

Comment as guest or Sign in

HTML tags are not allowed

Aug 17, 2021

Aug 24, 2021