Hi there, i am aware that this has been raised in the past however i would like to bring it up again - is there any chance of the number of custom fields increasing for Internal Controls?
Hello,
We will be adding relation custom fields in the next release (see the roadmap here: Product Roadmap (Last Update: 10th November)
), but we are not planning to change the limits of the existing custom fields. There are also some software limitations involved.
Could you elaborate on your use case? How many fields are you trying to add and why?
I have a very large enterprise i am deploying this in and we are estimating that we may breach just over 1500 controls because we are referencing many documents with different fields - each of which are different. i have made a plan but i am worried in the future due to scale that i will hit this bottleneck again.
if you have purchased consulting hours you should check your implementation with them before moving on.
what you describe is not common at all (no matter the size of the organisation). there is a big chance that what you are aiming is just not possible in eramba OR the method you have taken is simply not scalable.
definitely was thinking the same thing.
thank you for the insight- team.
Not sure I understand it right.
Here is my understanding of your approach and my suggestion on what I think is the same problem that we have solved differently.
My understanding: You do have a number of documents with different “fields” or “chapters” maybe. Within a particular document, some “fields” or chapters address (or “solve”) a particular requirement from a standard/norm you are adhereing to. You may have one document with five chapters, where each chapter is an implementation of one requirement of your standard/norm. To document this within eramba, instead of creating one control per document, you create one control per “chapter” or “field”, so that the mapping is more specific than just pointing to one large document.
(A side note: When you are talking about “controls” for documents, I really think the idea behind eramba is, that everything that is like “a piece of paper” goes into “Policies”, whereas “Controls” are things that actually do something)
Our situation: We do have a very similar problem. We implement ISO 27001 and we do have several Policies (processes, guidelines, procedures) to implement it. But some of these policies address multiple ISO 27001 requirements at once. One example is a Server Hardening Guide - it addresses controls for vulnerability management, backup, anti virus, change management, and more.
Our solution: We create the “Server hardening guide” as a “Policy” in Eramba. Just once. One list item for the entire document. Nothing more. When documenting the Compliance in the Compliance module, we do the following.
For each ISO 27001 requirement (“Compliance Package Item”) that is adressed by the Standard Configuration Guide, we select that Policy as a treatment. Additionally, in the comments section of the Compliance Package Item, we put what we call a “storyline”. This is text information, that guides you through the document, e.g.
“Standard Backup configuration is addressed in Chapter 3.4 Backup (p. 36) of ‘Server hardening guide’, as well as in ‘Veeam Monitoring’, which monitors success of backup jobs”
This text is helpful during an audit, when you see a document, but need to find the right page really quick.
Also it limits the number of “Policies” we maintain in Eramba to the actual count of documents we maintain, and in turn reducing the number of periodic reviews.
It also allows for a nice report with a tree graph showing the importance of certain documents.