Compliance that stays current, not rebuilt every audit.

Supplier Shield is Acuna's third-party risk management (TPRM) software. It gives you a scored vendor register, a daily-refreshed external security grade on every supplier, AI-assisted assessment campaigns that a human evaluator confirms, a supplier portal for external responses, and an immutable activity log that serves as your audit artifact for DORA, NIS2, and ISO 27001. Vendors are scored across three dimensions, dependency, reach, and impact, into one colour-coded risk tier. It is one module of the Swiss-hosted Acuna GRC platform, which maps to 50+ frameworks, so vendor evidence collected here is reusable across your wider compliance programme.

Each control in Acuna displays a colour-coded health badge — green (healthy), orange (at risk), or red (unhealthy). Health is driven primarily by recurring task completion: a task completed on time scores as healthy (100), completed late scores as at risk (75), in progress but not past due as at risk (75), and not started past due as unhealthy (0). These scores cascade upward through measures and requirements so operational slippage surfaces in the control and programme views, not only in a task list. Click any health badge for a breakdown explaining which tasks contributed to the current score.

Acuna supports four KPI data source types. Manual entry is for metrics from outside the platform (pen test scores, survey results). Computed KPIs calculate automatically from live compliance data using either a predefined metric library (grouped by Compliance, Operations, Risk, Controls, General, and Assure categories), a custom query builder with filters and operators, or a control-sourced effectiveness/execution feed. Connectors pull values from integrated external services. External API/webhook receives inbound values from systems that push data to Acuna. Per-item compliance thresholds with colour-coded progress bars are available for computed sources.

Operate is the day-to-day execution layer. It manages recurring tasks (with configurable frequencies and owners), objectives and KPIs, incident tracking, and third-party registers. Tasks drive control health: when a recurring task is completed on time, the linked control stays green; when it slips, the control turns orange or red, and that status cascades up to the measure and requirement. Operate also houses the KPI dashboard with manual, computed, connector, and webhook data sources, giving management real-time visibility into programme performance.

Each control can have one or more recurring tasks — for example, 'Review access rights quarterly' or 'Test backup restoration monthly.' Tasks are assigned an owner, frequency (daily, weekly, monthly, quarterly, annually, or custom), and a due date. When a task is completed on time, it scores 100 (healthy). Completed late scores 75 (at risk). In progress but not overdue scores 75. Not started past due scores 0 (unhealthy). These scores roll up to the parent control, then to the measure, then to the requirement — so a missed task surfaces as a visible gap at every level of the programme.

Enterprise Risk in Acuna provides a structured risk register where each risk is scored on likelihood and impact across configurable dimensions (financial, operational, reputational, regulatory). Risks are linked to controls, assets, processes, and owners. The module supports risk treatment plans (mitigate, accept, transfer, avoid) with action tracking, residual risk recalculation after control implementation, and heat-map visualisation for management reporting. Risk data integrates with other modules: a high-risk supplier in Supplier Shield or a failed control in Implement surfaces as a risk event automatically.

A CISO dashboard is a consolidated view of security, risk, and compliance indicators a Chief Information Security Officer needs to run their program. Effective CISO dashboards combine: multi-framework compliance posture (ISO 27001, NIS2, DORA, SOC 2), risk register with scoring and trends, control maturity by domain, and readiness for upcoming audits. In Acuna, each CISO configures their dashboard via RBAC to show only their scope, their KPIs, and the risks they own. Leadership sees the summary. Analysts see their controls. Same platform, different views per role.

A compliance calendar is a structured view of every review, audit, assessment, renewal, and regulatory deadline a compliance program must meet. Organizations running multiple frameworks (ISO 27001, SOC 2, GDPR, NIS2) face dozens of recurring obligations per year, from quarterly internal audits to annual surveillance audits to vendor reviews. Compliance calendar software consolidates these into one view, tracks ownership, and surfaces what's overdue. Without it, deadlines live in Outlook and on spreadsheets, making missed obligations common. In Acuna, the calendar spans every framework, every cycle, every owner, with alerts before due dates.

DORA requires financial entities to detect, manage, classify, and report ICT-related incidents. Major incidents must be reported to the competent authority in stages: an initial notification, followed by an intermediate report as the situation develops, and a final report once the root cause is known. The classification of what counts as "major" is based on criteria set out in the regulation and its technical standards, covering factors such as the number of clients affected, duration, geographic spread, data losses, and economic impact. Entities may also notify significant cyber threats voluntarily. Before you report, you classify. DORA and its technical standards define the thresholds that separate a major incident from a routine one, using materiality factors. Getting classification right matters because it determines whether the reporting clock starts at all. This is where a running incident process earns its place: if you cannot quickly assemble which clients, systems, and data an incident touched, you cannot classify it, let alone report it on time. DORA structures reporting in stages: an initial notification once you determine an incident is major, an intermediate report as handling progresses, and a final report with root-cause analysis. The precise deadlines for each stage are set by the regulatory and implementing technical standards and should be verified against the current published standard before you rely on them.

Under Article 23 of NIS2, essential and important entities must report significant incidents to their national CSIRT or competent authority in stages: an early warning shortly after becoming aware of the incident, a fuller incident notification, and a final report once the incident is handled. An incident is significant if it has caused or is capable of causing serious operational disruption or financial loss, or has affected other people through considerable material or non-material damage. Because NIS2 is a directive, the exact deadlines and mechanics are shaped by each member state's transposition, so confirm the specifics against your applicable national law. The staged structure exists so authorities get an early signal quickly, then a complete picture as the situation resolves. The reporting clock only starts once you determine an incident is significant, which is why fast, accurate classification matters as much as the reporting itself. NIS2 sets out when an incident is significant, based on the disruption or loss it causes or could cause, and the harm to others. National transposition and guidance sharpen these thresholds. Classifying correctly is the gate: misjudge it and you either over-report routine events or, worse, miss the clock on a reportable one. Reporting is a sequence, not a single filing: an early warning soon after awareness, a subsequent notification with a fuller assessment, and a final report after the incident is resolved including root cause and mitigation. The precise timeframes are set by Article 23 and national implementation, so verify the current figures for your member state before relying on them.