Since 2024 I have chaired the Technical Committee for Information Security and Cybersecurity, as shown in my CV. From that position, I am interested in the relationship between management decisions and technical work: who owns the system? Who approves access? And which service must be restored first when an outage occurs? Questions like these help make responsibility clear before any tools are chosen.
A shared language for risk
The NIST Cybersecurity Framework provides a general reference for organising discussion of risk management. I use it here as a shared language for discussion rather than a ready-made checklist; applying it starts from an assessment specific to each organisation and its services.
In management discussions I like to tie a risk to a specific service. For example, what happens if the attachments to existing applications cannot be accessed? And who is affected if an employee keeps their access after moving to another role? Framing the example this way helps non-specialists understand why a measure is needed, and makes it possible to identify the right decision-maker.
Access is a decision with a life cycle
I suggest treating access as a record with a start, a justification, a review and an end. Granting access to cover a temporary task should come with a set time for review. Separating data entry from approval may also matter in some procedures, depending on the nature of the service and the approved allocation of responsibilities.
Application access and automated integrations deserve the same attention. A service that reads another system's data needs a clear purpose, a defined scope and someone responsible for monitoring it. As integrations multiply, documenting the relationships between systems becomes part of understanding dependencies, and of being able to investigate when an error appears.
Business continuity is a testable question
Having a backup raises further questions: can it be restored? What data does it cover? And can the team run the service after restoration? These are examples of tests that should be designed for the specific working environment, taking care not to disrupt the live service and to protect users' data.
- Name an owner for each system and service and for its data.
- Review access when roles change or the need ends.
- Document the route for reporting and handling faults and incidents.
- Test restoration and record the observations and the tasks that result.
Progress in cybersecurity becomes clearer when each team knows what it is responsible for, when decisions can be documented and followed up, and when the person in charge can understand their effect on service continuity and on the trust of service users.