# Institutional security and control (https://docs.akollo.com/en/trust/institutional-security)



<Callout title="Planned">
  This area is planned. It is described here so you can prepare; it is not yet part of the current release.
</Callout>

## What it is [#what-it-is]

This area covers how Akollo is installed, which data may leave the institution, how long records are kept, how deletion is checked, and an audit trail that can be shown unchanged.

Employees are told what is collected and can ask to see or correct their records.

Separate controls cover sensitive content, devices, file transfers, blocked sites and closed applications. They are on only when a policy turns them on. A live view of a screen needs a second approver, a time limit and a visible sign for the employee.

## Forwarding security events to the SIEM [#forwarding-security-events-to-the-siem]

Security events go to the institution’s SIEM over an encrypted connection.

| Transport       | Formats                     |
| --------------- | --------------------------- |
| Syslog over TLS | CEF, LEEF or RFC 5424       |
| Splunk HEC      | Splunk HTTP Event Collector |

* Each event is delivered at least once and carries its own id, so the SIEM can drop repeats.
* An entry the SIEM refuses is quarantined and can be sent again.
* A delay of more than 15 minutes raises a warning event.
* The institution can also fetch the events page by page with an API key, only for its own organisation.

<Mermaid
  title="How a security event reaches the SIEM"
  chart="`flowchart LR
A[Security event] --> B[&#x22;Encrypted delivery (syslog over TLS or Splunk HEC)&#x22;]
B --> C{SIEM accepts?}
C -->|Yes| D[&#x22;Stored in SIEM, repeats dropped by event id&#x22;]
C -->|No| E[Quarantined]
E -->|Send again| B`"
/>

## Alerts and security incidents [#alerts-and-security-incidents]

The security team works on alerts and incidents on two pages under **Governance**.

The **alerts** page lists the alerts that rules raise, by state. A reviewed alert is either confirmed and linked to an incident, or dismissed with a reason.

The **security incidents** page filters incidents by severity, state, source, handler and resolve-by time. New incidents can be moved to triage together. An incident’s page has a summary, a timeline, the evidence, the incident’s own log and an export.

<Mermaid
  title="From alert to resolved incident"
  chart="`flowchart LR
A[Rule raises an alert] --> B{Review}
B -->|Dismiss with a reason| C[Alert closed]
B -->|Confirm| D[Linked to an incident]
D --> E[Triage]
E --> F[Resolved and classified]`"
/>

When an incident is resolved, it is classified as a real incident, expected behaviour, a false alarm or harmless.

### Privacy of the person concerned [#privacy-of-the-person-concerned]

The person concerned appears by a pseudonym everywhere. Seeing who it is takes a written reason. The identity is shown on that screen only, and the request goes to the audit trail.

The exported file holds the incident’s details and evidence digests, never the evidence itself or the person’s identity.

On a phone, the lists are shown as cards and the actions open in a panel from the bottom.

## Remediation register [#remediation-register]

The remediation register lists vulnerabilities and review findings, each with a due date.

* A scan result can be imported as a SARIF file, and a penetration-test result as a CSV file.
* Accepting a risk needs a reason and an end date.
* The person who owns the finding cannot accept it.
* When the acceptance date has passed, the finding is shown as open again.

## Control register [#control-register]

The control register shows frameworks, requirements, controls and evidence together. It can be downloaded as Excel or JSON. The file is a control mapping, not a certification.

The register comes with these requirement sets:

* ISO/IEC 27001:2022 Annex A (only the control number and short name);
* the BDDK information systems regulation (31069);
* KVKK requirements.

An organisation can load 16 ready-made controls with their mappings and evidence items in one step, or import the institution’s own requirement list as CSV. The “Control mapping” document explains which control contributes to which requirement.

<Callout type="warn" title="Warning">
  The control register is a mapping. Akollo claims no certification.
</Callout>

## Governance overview [#governance-overview]

The governance overview shows the security officer, the data protection officer and the auditor at a glance what is measured and what is not. Each card summarises one subject and links to its page:

* outside destinations and the data routing rule;
* encryption keys;
* the last audit trail verification;
* refused outside requests;
* open security incidents;
* data subject request deadlines;
* notice acknowledgements;
* compliance readiness and findings.

The backup and SIEM forwarding cards are for the installation administrator. People see the cards their access covers.

A fact that is not measured yet is grey. Green is used only for something measured and healthy. Cards hold counts and dates only, never a person’s name.

## FAQ [#faq]

<Accordions type="single">
  <Accordion title="Can I use this area today?">
    No. It is planned and not yet part of the current release. It is described here so you can prepare.
  </Accordion>

  <Accordion title="Which SIEM formats are supported?">
    Syslog over TLS in CEF, LEEF or RFC 5424 format, and Splunk HEC. The institution can also fetch events page by page with an API key.
  </Accordion>

  <Accordion title="Does the security team see the employee’s name in an incident?">
    No. The person appears by a pseudonym. Seeing the identity takes a written reason, it is shown on that screen only, and the request goes to the audit trail.
  </Accordion>

  <Accordion title="Does the control register make us certified?">
    No. The register and its export are a control mapping. Akollo claims no certification.
  </Accordion>

  <Accordion title="Can the owner of a finding accept its risk?">
    No. Accepting a risk needs a reason and an end date, and the owner of the finding cannot accept it. After the end date the finding is shown as open again.
  </Accordion>
</Accordions>