Institutional security and control

What it isCopy Anchor Link

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 SIEMCopy Anchor Link

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

• 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.

Alerts and security incidentsCopy Anchor Link

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.

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

Privacy of the person concernedCopy Anchor Link

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 registerCopy Anchor Link

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 registerCopy Anchor Link

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.

Governance overviewCopy Anchor Link

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.

FAQCopy Anchor Link