Comments input
During the course of compliance assessments, auditors inevitably record a certain number of violations.
The main mistakes that can be made at this stage are:
– Treating a violation/issue as one of the fields to be filled in with text during the audit.
– Treating issue input as the ultimate goal of the audit.
Why should all detected issues be treated as a separate entity within the audit framework? First of all, for proper monitoring, the comment must have at least the following attributes:
– Status
– Creation date
– Elimination date
– Author
– Responsible staff
– Completion date.
This is already more than something that will comfortably be stored within one, two, or three fields. However, the list of required attributes does not end there. With respect to the comment, it is also important to record:
– For which asset was it initiated?
– In the context of which audit?
– What requirement was violated?
– What evidence was attached ref the violation?
With an elaborate audit process, the list of attributes can be much longer. The organization may introduce a classification of comments as well as a record of recurring comments.
This number of attributes leads to classic problems: the disparity of the format of the data to be filled in, human errors, and difficulties with the manual updating of data. In the end, the more forms the expert has to fill out during the audit, the less time and effort he has left for anything beyond manual operations.
Obviously, the SGRC system you choose to automate the mentioned processes should easily cope with the problems of the issue management stage described above as well.
Processing comments
As mentioned earlier, the maturity of the audit management process can be evidenced by the attitude of the participants toward what the result of the audit is. A report? A completed questionnaire? A list of violations?
All of these things are undoubtedly important but the ultimate goal of such upper-level cyber security processes should be to strive for improvement of the cyber security system, i.e. to form a clear vision of what needs to be improved, how, in what time frame, and by whom. In the context of audits, a plan to eliminate issues becomes such a tool.
There are different approaches to forming such plans. In small organizations, the list of comments immediately generates a list of tasks for the end executors. In larger organizations, the process may become more complicated: the parties agree on issues, then create a high-level strategy for their elimination, and only then – after the audit is completed – the audited party decomposes it, sometimes sending tasks to colleagues from other departments (most often IT).
One way or another, having a plan for eliminating issues and monitoring its implementation is a guarantee that the audit was not wasted for the sake of beautiful reporting. It allows for assessing the scope of work, and the required budget, as well as tracking the progress of changes and assessing the overall compliance of assets more accurately.
Automation with SGRC systems is crucial at this stage because:
– Those responsible for executing the plan must have a clear understanding of the status of all planned work.
– The completion of tasks by the executors should be reflected in the progress of the plan implementation.
– The gradual closure of tasks from the plan should lead to the closure of related issues.
At the same time, it should be taken into account that formally an issue can be recorded in relation to the system, while the task should be implemented on the equipment included in it. Such links should not be lost.