Evidence for an external audit
An external auditor, a customer’s security questionnaire, or a NIS2 Art.21 review all want the same three things: a record of what changed in your infrastructure, attribution for each change, and a current picture of what you actually run. You need to hand that over without giving anyone the ability to alter it, and without spending a week assembling it by hand.
Sencai holds all three. Every mutating action - by a person or by an automated process acting for you - lands in an append-only, hash-chained audit log that nobody can edit or delete, including Sencai. Inventory holds the resource side of the picture. A filtered view of that same log is packaged as a NIS2 evidence timeline you can export as CSV or PDF.
What Sencai does not do is finish the job. It does not certify your organization as compliant with anything, does not map a log row to a specific NIS2 article or control number, and does not produce a finished report. Everything below is a primary evidence source your compliance team draws on - the write-up is still yours. Read Compliance overview first if you want that boundary stated in full.
What this looks like in Sencai
Section titled “What this looks like in Sencai”1. Decide what the auditor sees, before you invite them. The role built for this is Auditor: read-oriented, scoped toward audit and compliance visibility, and positioned below Admin in the hierarchy - Owner > Admin > Member > Auditor > Viewer. It is not an elevated role, so do not grant it expecting Admin-like reach. Roles & permissions has the full table, and Organizations & teams covers the invite itself. An invitation grants nothing until the invited person accepts it.
2. Understand the record itself. Audit log is the page to read before you show anything to a third party, because it defines the evidence’s properties: each entry carries the action, the actor and the organization they acted as, the affected resource, what changed, a risk level, a correlation ID, source IP and user agent, and a timestamp. Each entry’s hash includes the previous entry’s hash, so altering history breaks the chain from that point forward. Entries are retained indefinitely and cannot be deleted or edited by anyone.
3. Produce the export. There is no in-app search screen over the raw log. The
way you get data out is Settings → Audit Export
(/gravity/settings/audit-export): pick a date range, optionally narrow by action,
resource type, and risk level, then request CSV or JSON. Up to 10,000 rows come back
immediately; larger runs, up to 100,000 rows, process in the background and appear
in the export history on the same page.
4. Show what you run. The “what do you operate” half of the question is
Inventory, at Compliance & Audit → Inventory
(/gravity/inventory) - every resource discovered in your connected provider
accounts plus software reported by enrolled hosts, each with its provider identity,
tags, and one of four ownership states (Unmanaged, Managed, Read-only, Ignored).
Two sub-views are usually the ones an auditor asks for by name: Drift
(/gravity/inventory/drift), the record of changes made outside Sencai, and
Software (/gravity/inventory/software), the installed-package view across
enrolled hosts. Both export the currently filtered view.
5. Hand over the NIS2 timeline. NIS2 evidence, at
Compliance & Audit → NIS2 evidence (/gravity/inventory/evidence), is the
packaged version: the same audit log, filtered to discovery scans, ownership
changes, tagging, and drift detection and acknowledgment, with a before/after
comparison where one applies. Filter by action type, resource, and date range, then
export CSV for further processing or PDF for a print-formatted, timestamped excerpt
you can attach to an audit pack as-is. This view is part of the Business plan and
above - see sencai.space/pricing.
6. Answer “who authorized this”. When the review asks who signed off on a
high-impact change, Approvals at Compliance & Audit →
Approvals (/gravity/approvals) holds the decision record: the requested action,
the requester, the blast radius, and - through its History tab - who approved or
rejected it and the written reason a rejection required. Those decisions land in the
same audit trail as everything else.
What will surprise you
Section titled “What will surprise you”The NIS2 timeline is not a second source. It is a filtered window over the same audit log the export in step 3 draws from, not an independent record. If an auditor asks you to corroborate one against the other, the honest answer is that they are the same data seen through two filters. Present them that way; a reviewer who discovers it on their own will wonder what else was oversold.
There is no search screen over the raw log. You cannot answer an auditor’s ad-hoc question in the app by typing into a search box. You request an export, wait for it, and search the file. Budget for that round trip when the reviewer is sitting in a meeting room asking follow-ups.
There is no self-service chain verification. The log is hash-chained, and that property is real, but no button in the app proves it to a third party. If your review requires an independent chain-integrity check rather than your assertion that one is possible, that has to be arranged with your account team - so raise it at the start of the engagement, not the week the report is due.
Export files expire after seven days; the data behind them does not. Do not treat a download link as your archive. Save the file somewhere you control the retention of, and request a fresh export rather than trying to recover an expired one.
The timeline is an activity log, not a control mapping. No row is tagged with a NIS2 article or a control number. Turning “who tagged which resource when” into “therefore Art.21(2)(d) is satisfied” is entirely your compliance team’s work.
Audit export is broader than the role model suggests. The role model designates Owner, Admin, and Auditor as the roles with direct read access to the audit trail, but any member of your organization can request an audit export today. If your control narrative says only certain people can extract the audit trail, verify that claim against your own account before you write it down.
Approvals have no role floor. Any member of the organization a request belongs to can approve or reject it - not only Owners and Admins - and there is no delegation or assignment mechanism. Pending requests expire after four hours if nobody acts. If your policy is that only two named people approve production changes, that is a process agreement inside your team, not something the app enforces, and an auditor who reads the screen will see that.
Drift is recorded, not reverted. A change made directly in a provider console is captured with a severity and a before/after comparison, and someone acknowledges it. Sencai does not undo it. Absence of open drift means someone acknowledged it, not that the resource was put back.
What’s next
Section titled “What’s next”- Audit log - what each entry records, how the chain works, and the export screen
- NIS2 evidence - the filtered timeline and its CSV/PDF evidence pack
- Inventory - the resource record behind the activity, including drift and software
- Roles & permissions - where Auditor sits and what it does and does not grant
- Compliance overview - how these pieces feed each other, and what stays your responsibility