A Czech organisation preparing incident reports should connect its service ownership, incident timeline and evidence review into one controlled workflow. The software should help an authorised person assemble a consistent account of what happened and what remains unknown. It should preserve the distinction between collecting evidence, deciding reportability and submitting through the approved channel.
NÚKIB describes its Portal as the communication platform used under the cybersecurity framework from 1 November 2025. Its incident-reporting guidance identifies electronic portal forms as the primary reporting route for regulated entities and explains transitional and outage arrangements. The organisation’s responsible reviewers must establish the obligations and timing that apply to its services.
Begin with the service, not the alert title
Consider a fictional Czech software operator that receives monitoring alerts for several customer-facing services. Its service desk records the affected server, while customer support records user complaints in another application. Neither record clearly identifies the accountable service owner or the business impact.
A reporting workflow needs that connection. Establish a maintained service register with an owner, supporting systems and approved escalation contacts. Link an incident to the affected service even when the investigation later changes its view of the technical cause.
Do not let the name of a monitoring rule become the incident’s final description. An alert can be a clue, a duplicate or a false positive. Preserve it as evidence while allowing the incident team to develop a reviewed account.
Keep observation and interpretation separate
Create a timeline that distinguishes when an event occurred, when it was detected and when the organisation learned a new fact. Record the source of each entry. If the exact event time is unknown, retain that uncertainty rather than filling a convenient value.
For a proposed first release, an evidence item might include a source reference, collection time, responsible person, access classification and a short explanation of relevance. A separate review field can state the current interpretation. This helps later reviewers understand which statements were direct observations and which were working hypotheses.
Limit attachments to material needed for the investigation and approved reporting purpose. A raw log bundle can contain credentials, personal information or unrelated customer records. Give the team a controlled review and redaction process instead of copying every available file into a broadly accessible ticket.
Define the approval path before an emergency
The incident commander, technical investigator, service owner and authorised reporting contact may be different people. Document who can change the incident classification, approve an external statement and submit the required form.
The application should expose missing approvals and unavailable owners. It should also support a documented deputy arrangement. A workflow that waits indefinitely for one absent employee can make a technically complete report operationally unusable.
Configure reminders from the organisation’s reviewed obligations and incident categories. Do not hard-code a single universal deadline into the product and assume it covers every entity or transitional situation. Record the rule version used so future reviewers can explain why a reminder was generated.
Build a report package with traceable fields
A useful package can contain:
- ▸The affected service and accountable organisation.
- ▸The reviewed incident summary and known operational impact.
- ▸A timeline with source references and explicit uncertainties.
- ▸Measures already taken and the person responsible for each update.
- ▸Contact details approved for incident coordination.
- ▸A list of evidence attachments with access restrictions.
- ▸The approval history and reference to any previous submission.
Map these proposed fields to the current official form and the organisation’s actual requirements during discovery. The package should help the authorised reporter complete the approved process. This article does not assume that a public submission API exists or recommend automating a regulator’s portal without an authorised integration route.
Test the report while the service is still changing
Incident information evolves. A first account may state that one service is affected; later investigation may reveal a shared dependency. The workflow should make corrections visible and preserve the earlier approved version.
Use an exercise in which customer impact changes halfway through preparation. Ask the team to produce an updated package and show what changed. Then introduce a conflicting technical note. The reviewer should be able to resolve or retain the uncertainty without deleting the source evidence.
Include a duplicate alert from another monitoring tool. The team needs to associate it with the existing incident rather than inadvertently create two independent reporting workflows with inconsistent descriptions.
Rehearse the unavailable-system scenario
NÚKIB’s guidance describes temporary alternatives when its portal cannot be used. The internal runbook should point to the current official instructions and identify who verifies the appropriate route. Keep this information accessible if the primary service desk is itself affected.
Your own workflow also needs recovery planning. Test whether authorised staff can retrieve the latest approved incident package during an application outage. Review backup access, contact availability and the method for reconciling offline notes afterward.
A successful exercise ends with a consistent record of what was prepared, approved and actually submitted. A local “complete” status should never imply external submission when the organisation has no evidence that it happened.
Scope the integration around existing tools
TuniCyberLabs can help connect service desks, asset records and evidence review through custom software development. Send a Czech incident-workflow brief with your current tools, service ownership gaps and reporting responsibilities. The maintenance service-agreement guide can help define who supports this workflow after delivery, including access reviews, rule updates and recovery exercises.