What is Supplier Shield?
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.
How does control health scoring work in Acuna?
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.
What are KPI data sources in a GRC platform?
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.
What does the Operate pane do in Acuna?
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.
How do recurring tasks drive compliance health in Acuna?
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.
How does enterprise risk management work in Acuna?
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.
What is a CISO dashboard?
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.
What is a compliance calendar and why does it matter?
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.
How does DORA incident reporting work?
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 three stages. You file an initial notification within 4 hours of classifying the incident as major, and no later than 24 hours after you became aware of it. An intermediate report follows within 72 hours as handling progresses, and a final report with root-cause analysis within one month. These time limits are set in RTS 2025/301, with the reporting templates in ITS 2025/302, under Article 19 of DORA.
How does NIS2 incident reporting work?
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 within 24 hours of becoming aware of the incident, a fuller incident notification within 72 hours, and a final report within one month of that notification. 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. These windows are fixed in Article 23(4) of the directive, so the 24-hour, 72-hour, and one-month deadlines are the same in every member state. What national transposition changes is the authority or CSIRT you report to and the reporting mechanics, so confirm your reporting route for the country where you operate.
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 within 24 hours of awareness, a notification within 72 hours with a fuller assessment, and a final report within one month of that notification covering root cause and mitigation. If the incident is still open at one month, you file a progress report and a final report once it is resolved. The timeframes come from Article 23(4) of the directive and do not change by member state; national implementation sets the authority you report to and the mechanics, not the windows.