Change intent for your whole estate
Every change in your environment, and why it happened.
Other tools tell you what changed. Nakana tells you why: the ticket, the commit, the pipeline run and the person behind each change. When a change has no good reason, you hear about it the same day, not at the audit.
Nakana is Croatian for intent. We're taking a small number of design partners now.
Why: ships PR #4821 "Retry on upstream 502". Two approvals, built by GitHub Actions, inside the approved window for CHG0031207.
Why it's flagged: made with a break-glass account. No ticket, no commit. The DBA who checked out the account has made no privilege grants in 180 days, and has never worked at this hour.
Why: CHG0031244 allows SSH from the vendor's range, not from anywhere. It was made in the console on a Terraform-managed resource, so the next plan will show drift.
Why: standard change template "Open monitoring port", requested by the NOC on-call, applied by Ansible job 5531.
The problem
You can see what changed. Nobody can tell you why.
File integrity monitors, cloud config logs and observability tools record changes by the thousand. Matching each one to a reason is still done by hand: someone exports the change log, opens ServiceNow, opens GitHub, and pieces it together before the auditors arrive.
Change evidence is a spreadsheet
SOX, PCI DSS and SOC 2 all ask the same thing: was every production change authorized, tested and approved? Today that answer comes from sampling and screenshots.
The risky change looks like every other change
A privileged user granting themselves access at 2 a.m. lands in the same log as 1,200 routine deploys. Without a reason attached to each one, the odd one out doesn't stand out.
Incidents start with "what changed?"
Most outages follow a change. Responders spend the first hour finding it, then another finding who made it and whether it was meant to happen.
How it works
See the change. Find the reason. Judge the reason.
Every change, every layer
Read-only API connections and the log platform you already run record changes to code, pipelines, cloud, Kubernetes, hosts, databases and network gear in one format. No agent on your servers.
Who, really
Service accounts, shared admin logins and pipelines get traced back to a person, using your identity provider, PAM checkouts and HR directory.
Why it happened
Nakana links the change to the change request, commit, pull request, pipeline run, deploy or incident that caused it, and writes the reason in plain English.
Does the reason hold up?
Each change is checked against the ticket's scope and window, the person's normal behavior and your policies. The ones that don't add up get flagged.
Coverage
One change record across your whole estate
Intent is only useful if it covers the whole path a change takes, from a developer's laptop to a router config.
Dev environments
Repos, branches, merges, branch protection changes, secrets, developer workstations.
CI/CD
Pipeline runs, workflow edits, artifacts, signatures, deploys and rollbacks.
Production
Releases, feature flags, config pushes and manual hotfixes.
Cloud
AWS, Azure and Google Cloud control-plane changes, IAM, networking and drift from IaC.
Kubernetes
Audit log, workloads, RBAC, admission policies, GitOps syncs and kubectl edits.
Servers and machines
Files, packages, services, users, sudo, kernel modules and registry, via eBPF, auditd and Windows events.
Databases
Schema changes, grants, roles, parameters and direct writes to sensitive tables.
Network devices
Running-config diffs, ACLs, routes and firewall policy on switches, routers and firewalls.
Identity-aware
It knows your people, not just your accounts.
Nakana connects to your identity provider and HR system, the way enterprise search tools read your org chart. So it knows who reports to whom, who is on call, who is on leave, and who normally touches production.
That's what makes a flag worth reading: "a DBA changed a database during a change window" is normal. "A DBA on PTO used a break-glass account to grant superuser at 2 a.m. with no ticket" is not.
Signals we weigh on every change
- Matches an approved change request, in scope and inside its window
- Traces to a reviewed commit and a pipeline run, or was made by hand
- Made at a time and from a place normal for this person
- First time this person has made this kind of change
- Made with a break-glass, shared or dormant account
- Made by hand on a resource managed by Terraform or GitOps
- Made during a change freeze or an open incident
- Unusual for this person's team and role
- Touches a library or host with a CVE on CISA's exploited list
Built for the audit
Change management evidence that writes itself
Every change comes with its reason, approvals and the person who made it. Auditors get a full population, not a sample, and the exceptions list is short because you already dealt with it.
SOX ITGC
Program change and access controls, with every change tied to its approval.
PCI DSS 4.0
Change control (6.5), audit trails (10) and change detection on critical files (11.5).
SOC 2
CC8.1 change management and CC7 monitoring, evidenced continuously.
ISO 27001, DORA, NIS2
Change management and ICT risk evidence for EU and international frameworks.
Works with what you run
Bring your change tickets, your logs and your pipelines.
ServiceNow, Jira, GitHub, GitLab, Datadog, Splunk, AWS, Kubernetes, Okta, Entra ID and more than 150 other sources. Nakana adds the reason to data you already collect, and pulls vulnerability context from the scanners you already run.
Browse integrationsHow we're different
They record the change. We explain it.
Integrity monitors, cloud posture tools and change-tracking features in observability platforms are good at telling you something changed. Few check it against a ticket, and none tells you whether the reason holds up.
Compare approachesEarly access
Tell us how you track change today.
We're looking for a few design partners in regulated industries: financial services, healthcare, payments and SaaS with SOC 2 or SOX scope. Partners shape which integrations ship first.