Three compliance processes, one accountable method
Three everyday compliance processes: approving new documents, managing incidents and training employees. Each one works best with clear steps, named owners and records – and AI assistants can help with the reading, comparing and drafting while people decide, approve and sign.
Document approval: new policies, procedures and process changes
Every new or changed document goes through the same seven stages. The first four form the review; the last three close the loop to an approved, published and acknowledged document.
Keep the rulebook
Approved, versioned sources
Submit the document
Owner, version, scope; no personal data
Review and cite
Ratings, severities, proposed fixes
Officer validates
Confirms, amends or rejects; signs
Fix and re-review
Owner corrects; review again
Approve
Responsible body approves
Publish and acknowledge
Staff confirm; training
| Stage | Who | What happens | Result |
|---|---|---|---|
| 1. Keep the rulebook | Rulebook administrator; a second compliance officer checks | EU and national law, supervisory guidelines, internal policies and a requirements register that splits each source into single obligations. Each document has an owner, version, effective date and status; upcoming rules are labelled; old versions are archived, never overwritten. | A numbered rulebook version, quoted in every review |
| 2. Submit the document | Process owner | The draft or changed document with owner, version, date and scope. Customer and confidential personal data are removed first. | An accepted submission |
| 3. Review and cite | Compliance reviewer, optionally supported by an AI assistant | Maps each step to the applicable requirements, rates each one, checks control quality (owner, control, evidence, time limit, escalation), flags conflicts between sources, says “not covered” where no rule exists and drafts replacement wording for Critical and Major findings. | A report in a fixed structure, with a citation for every finding |
| 4. Officer validates | Named compliance officer; second reviewer for any Non-compliant rating | Checks citations against the original source and confirms, amends or rejects each finding with a reason. Sets the final severity. | A signed review record |
| 5. Fix and re-review | Process owner; reviewer | The owner corrects the document within the deadline for each severity. The corrected version is reviewed again against the same or a newer rulebook version. | Findings closed or accepted with a reason |
| 6. Approve | The body named in the organisation’s rules (e.g. management board, head of unit) | Approves the document on the basis of the signed review. Critical findings stop go-live until fixed. | Approved version with date and approver |
| 7. Publish and acknowledge | Document owner; employees | The approved version is published to the people it applies to, who confirm they have read and understood it; a short course or quiz can be assigned (see Training). | Acknowledgement and training records |
Requirement ratings
| Rating | Meaning |
|---|---|
| Compliant | The process meets the requirement |
| Partially compliant | The requirement is addressed, but with gaps |
| Non-compliant | The process appears not to meet the requirement; a second reviewer confirms |
| Not applicable | The requirement does not apply to this process |
| Not assessable | The text does not allow a conclusion; more information is needed |
Finding severity
| Severity | Meaning | Typical action* |
|---|---|---|
| Critical | Legal requirement or key control appears not met, with direct risk (e.g. customer harm, AML exposure, invalid terms, no segregation of duties) | Stops go-live; escalated to the head of compliance |
| Major | Legal requirement or key policy parameter appears not met, without immediate critical impact | Fixed before go-live or under an approved plan |
| Minor | Documentation, timing or retention gap with limited impact | Fixed within an agreed period |
| Observation | Improvement point without a breach | Considered at the next review |
* Escalation periods are set by each organisation in its finding classification policy.
Example finding (illustrative)
Incident management: one intake, several regulatory clocks
A single incident – for example a cyber attack on a loan system – can trigger reporting duties under several laws at once, each with its own deadline and authority. A clear process makes sure nothing is missed.
Detect and report
Anyone reports; time of awareness recorded
Triage and classify
Type, impact, severity
Assess reporting duties
Which laws, which deadlines
Contain and remediate
Limit harm, restore service
Notify
Authorities, customers, partners
Root cause and lessons
Fix causes, update documents
| Stage | What happens | How tools and AI can help |
|---|---|---|
| 1. Detect and report | Staff, systems, suppliers or customers report a possible incident through one intake point. The time the organisation became aware is recorded – most deadlines run from it. | Guided intake form; asks the questions needed for classification; flags possible personal data, ICT or AI involvement. |
| 2. Triage and classify | The incident owner assesses type and impact: personal data breach, significant incident under NIS2, major ICT-related incident under DORA, serious incident involving a high-risk AI system. | Shows the classification criteria from the rulebook with citations; proposes a classification for the owner to confirm. |
| 3. Assess reporting duties | The compliance officer decides which reports are required, to which authority and by when. | Calculates the deadlines from the time of awareness or classification and keeps the clocks visible. |
| 4. Contain and remediate | IT, security and business teams limit the harm, preserve evidence and restore services. | Checklist from the incident procedure; records actions with time stamps. |
| 5. Notify | Authorised people submit the notifications and inform affected people where required. | Drafts notifications from templates and checks them for completeness. Only authorised people submit them. |
| 6. Root cause and lessons learned | Root cause analysis, final reports, corrective actions and updates to policies, procedures and training. | Links corrective actions to the document approval and training processes; keeps the full record for audit. |
Reporting deadlines at a glance
| Regime | What must be reported | Deadlines | To whom / notes |
|---|---|---|---|
| GDPR Regulation (EU) 2016/679, Art. 33–34 | Personal data breach, unless it is unlikely to result in a risk to individuals | To the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware; later notifications must give reasons. Information may be provided in phases. Affected individuals: without undue delay if the breach is likely to result in a high risk. Processors inform the controller without undue delay. | In Slovenia: the Information Commissioner. Every breach is documented internally, even if not notified. |
| NIS2 / ZInfV-1 Directive (EU) 2022/2555, Art. 23; ZInfV-1, Art. 29–30 | Significant incident of an essential or important entity | Early warning within 24 hours of becoming aware; incident notification within 72 hours; intermediate report on request; final report within one month after the notification (a progress report if the incident is still ongoing). | Competent CSIRT under ZInfV-1. Check national procedures and forms. |
| DORA Regulation (EU) 2022/2554, Art. 19; Delegated Regulation (EU) 2025/301, Art. 5 | Major ICT-related incident of a financial entity | Initial notification within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it; intermediate report within 72 hours of the initial notification (updated when regular activities are recovered); final report no later than one month after the latest intermediate report. If classified as major later, the initial notification is due within 4 hours of classification. Special rules apply to weekends and holidays. | Competent authority (for banks in Slovenia: Banka Slovenije; significant banks’ reports are passed to the ECB). Clients are informed without undue delay where their financial interests are affected. For financial entities DORA generally takes precedence over NIS2 reporting. |
| AI Act Regulation (EU) 2024/1689, Art. 73 | Serious incident involving a high-risk AI system | Providers report immediately after establishing a causal link (or its reasonable likelihood), and not later than 15 days after becoming aware; 2 days for a widespread infringement or serious disruption of critical infrastructure; 10 days in the event of a person’s death. An incomplete initial report may be followed by a complete one. | Market surveillance authority. Deployers inform the provider. Application date uncertain: the 2026 Digital Omnibus postponed the high-risk rules to 2 December 2027 (Annex III) and 2 August 2028 (Annex I); check when Art. 73 applies to your system. |
Deadlines summarised from the official texts as of October 2026. Sector rules (for example payment services, medical devices or aviation occurrence reporting) can add further duties. Always confirm against the current official texts and your authority’s guidance.
Employee training and certification
Rules only work when people know them. A good training programme covers both the law – from AI literacy to data protection and cybersecurity – and the organisation’s own policies, and keeps evidence of who learned what and when.
Assign by role
Learning paths per role or department
Learn
Short courses on rules and policies
Quiz
Check questions with explanations
Certificate
Issued on successful completion
Evidence
Per-person training record
Renew
Periodic or when rules change
Courses and quizzes
Courses per regulation and role – employees, managers, management body, IT, data protection – plus the organisation’s own policies, each with short check questions.
Role-based learning paths
Mandatory curricula by role or department, with deadlines and reminders, so each person learns what applies to their work.
Certificates and renewals
Certificates on successful completion, with a validity period and re-certification when it expires or when a law or policy changes.
Evidence of AI literacy
AI Act Art. 4 requires providers and deployers of AI systems to take measures on AI literacy. Since the 2026 Digital Omnibus, the duty is to take measures to support the development of AI literacy of staff, without guaranteeing a specific level. A documented, role-based training record is a practical way to show those measures.
Policy acknowledgement
When a document is approved and published, staff confirm they have read and understood it, optionally with a short quiz. This closes stage 7 of document approval.
Training for management
NIS2 requires members of management bodies to follow cybersecurity training, and DORA expects management to keep sufficient knowledge of ICT risk. Training records show who completed what and when.
Tools support; people decide
Always done by people
- Approve the sources in the rulebook
- Validate or change every finding and set the final severity
- Interpret the law together with Legal
- Approve documents or send them back
- Classify incidents and decide on and submit notifications
- Sign off training programmes and certificates
Never left to an AI tool
- Decisions about individual customers or credit applications
- Legal advice or a final legal interpretation
- Submitting reports to authorities
- Working with customer data or confidential personal data in a review
- Using sources that are not approved, dated and versioned
Talk to us about your compliance needs
Get in touch for a conversation about document approval, incident management or employee training in your organisation. Tell us your sector (bank or financial institution, public sector body or SME) and the rules you work with.
Contact
E-mail: [email protected]
Please do not send customer data or confidential documents by e-mail.