Skip to main content
qorionix

What an auditor will ask for

The ten things an auditor, an insurer or a large customer actually asks for, exactly where each comes from in the platform, and the ones we cannot produce.

Written for an audit response10 min readUpdated

Auditors, insurers and the security teams of large customers ask for remarkably similar things, in remarkably similar order. This article is the practical list: ten requests, where each one comes from in this platform, and what it looks like when it arrives. The last section is the list of requests we cannot answer, which is the more useful half — a vendor who claims to cover everything is a vendor whose claims you will have to walk back in front of a reviewer.

Two habits make the rest of this easy. Generate a stamped evidence bundle at the end of each review period and keep it, because a live query describes today and an auditor is asking about a window. And volunteer your gaps before they are found; a reviewer who discovers a limitation you did not mention discounts everything else you said.

The ten requests

The ten most common evidence requests, the source of each in the platform, and the form it arrives in
The requestWhere it comes fromWhat it looks like
1. Who has access, at what levelYour organisation's memberships and role assignments, plus the permission catalogue behind the roles. Also the evidence behind NIS2 control A21-9, which requires at least one row to report as met.A membership list with a role against each person, and each role's permissions as resource.action. See Who can see and do what.
2. Change history — what changed, when, by whomYour audit_logs table. Actions carry prefixes such as role., organization., user., mfa. and auth.; actions taken by Qorionix staff appear with no user attached and a support. prefix, which is how you tell them from your own users'.A dated sequence of actions with an actor. Posture changes additionally carry the decision you took — approved, rejected or accepted.
3. Incident recordsThe NIS2 incident register, and per incident an export shaped for a regulator submission.Incidents with severity, state and detection time, plus a full disclosure export per incident.
4. Proof of log retention and coverageYour licence's retention period and the sources you have connected. Read the caveat two sections down before answering this one.A retention figure in days and a list of connected sources with their health. Detection coverage is published against MITRE ATT&CK.
5. Evidence that access is periodically reviewedThe weakest row in the list, and asked by NIS2, DORA and SOC 2 alike. The platform does not run access certification today.Nothing generated automatically. What you can assemble: the permission catalogue, the audit log, and the posture findings on administrator accounts — see Access reviews and certification.
6. A risk assessmentThe posture assessment: 82 deterministic checks over your Microsoft 365 estate, each finding carrying a rationale, an attack narrative, a remediation with its cost, and framework tags.A named-findings report — real administrators, applications and devices — with severity and blast radius, plus an explicit list of checks that could not be evaluated and why.
7. Supplier and third-party due diligenceThe ICT third-party vendor register and the concentration view over it. The evidence behind NIS2 A21-4 and the substance of DORA's supply-chain articles.A vendor register plus a concentration analysis showing where your dependency is clustered — the part reviewers actually interrogate.
8. Multi-factor authentication coverageThe posture checks on authentication, and the NIS2 A21-10 evidence query over users with multi-factor enabled.A count and a coverage statement with named exceptions. ZQ-M365-AUTH-001 is the finding most questionnaires are really asking about.
9. Encryption and key managementStated facts rather than a generated artefact: TLS 1.2 minimum with 1.3 preferred in transit; AES-256-GCM with envelope encryption and a per-vault data key for privileged credentials, the key-encrypting key in a managed key service; bcrypt for passwords; one-way hashes for API keys; backups encrypted before upload under a key separate from production.A paragraph you can paste. This is the evidence behind NIS2 A21-8.
10. Proof the audit record has not been alteredHash-chained audit trails, one chain per framework, with a verification endpoint.A boolean per framework, and on the bundle's front page a chains-verified count of n/m. Read Verifying the audit chain before describing this to anybody — the guarantee is real and narrower than it sounds.

The endpoints behind those rows

Everything above is reachable over the API as well as through the console, which matters when a reviewer wants raw data for their own tooling rather than screenshots. The permission each one needs is worth knowing before you delegate the job of answering a questionnaire.

Evidence endpoints, with the permission each requires
compliance:evidence (read)
  GET  /api/v1/organizations/{orgID}/compliance/evidence/bundle
  GET  /api/v1/organizations/{orgID}/compliance/evidence/bundle/document
  GET  /api/v1/organizations/{orgID}/gdpr/export

compliance:evidence (write)
  POST /api/v1/organizations/{orgID}/compliance/evidence/bundle/stamp?actor=

compliance:frameworks (read)
  GET  /api/v1/organizations/{orgID}/compliance/nis2/conformity
  GET  /api/v1/organizations/{orgID}/compliance/dora/vendors
  GET  /api/v1/organizations/{orgID}/compliance/dora/concentration
  GET  /api/v1/organizations/{orgID}/compliance/gdpr/ropa
  GET  /api/v1/organizations/{orgID}/compliance/audit/verify?framework=
  GET  /api/v1/compliance/mappings/iso27001
  GET  /api/v1/compliance/mappings/soc2

compliance:breaches (read)
  GET  /api/v1/organizations/{orgID}/compliance/nis2/incidents
  GET  /api/v1/organizations/{orgID}/compliance/nis2/incidents/{id}/enisa

Note the split. compliance:frameworks covers control results, mappings and chain verification — the things that describe your posture. compliance:evidence covers producing and stamping exports. compliance:breaches covers incident disclosure, which is the most sensitive of the three, because an incident export is a full account of something that went wrong. Granting one does not grant the others.

Reading your own audit log
GET /api/v1/organizations/{orgID}/audit?actor=&action=&from=&to=&limit=&offset=

from and to are RFC 3339 timestamps

each row returns:
  id, user_id, action, resource_type, resource_id,
  ip_address, success, created_at

The retention question, answered honestly

Request four looks simple and is the one most often answered wrongly, including in vendor documentation. Your licence carries a retention period in days, and that period is applied as a clamp on how far back a log search may reach. There is no retention-driven deletion job in this version.

So the accurate answer to "how long do you retain our logs" is a statement about searchability rather than deletion: events older than your retention period are filtered out of your queries and are still present in storage. Say that. If your own policy document promises deletion after a fixed period, it is describing something the platform does not do, and correcting the document is much cheaper than having a reviewer find the difference.

What the subject-request run actually returns, per module
POST /api/v1/compliance/gdpr/dsr/{id}/run

for kind=erasure, each of the five dispatchers reports:
  "erased"

for kind=access or kind=portability, each reports:
  {"module": "siem", "status": "stub"}

The literal "status": "stub" in an access export is the platform telling you the truth about itself, and it is the string to look for if you are checking whether this has changed in a later release. The word "erased" on an erasure run is not — it is a success report from a dispatcher that did nothing. Note also that the statuses in_progress and rejected exist in the model and nothing ever writes them, so a request you decline still reads as completed.

One more thing worth knowing about the control results themselves: the NIS2 conformity evaluation is a live snapshot and is not written to a history table, so there is no series of past evaluations to show a trend from. The stamped bundle you generated at the time is the only durable record of what the controls said then. That is the practical reason to generate one per review period rather than on demand at audit time.

The requests we cannot answer

Ten rows, each of which will appear on some questionnaire. Knowing them in advance turns an awkward silence into a prepared sentence, and a prepared sentence about a gap reads as competence rather than as a shortfall.

Requests the platform does not answer, and what to say instead
The requestThe honest answer
A penetration test reportWe do not test your estate and the platform produces no such report. Commission one; it is a separate exercise with a separate deliverable.
Evidence of a tested backup restoreThe platform cannot evidence this. NIS2 control A21-3 is evidenced by proxy — licence events standing in for continuity evidence — and a competent auditor may decline the proxy. Attach your own restore report.
A security awareness training registerAlso a proxy: A21-7 uses the privileged audit trail as evidence of hygiene in practice, which is not evidence of training. Attach your own completion register.
A SOC 2 report or an ISO 27001 certificateThe platform holds a SOC 2 mapping and an ISO 27001 mapping. A mapping is not a report and not a certificate, and nothing here issues either. See How findings map to DORA and ISO 27001.
Access certification recordsProduced today. Identity → Access reviews runs a campaign over a scope you choose and exports the dated, attributed, per-entitlement record, with group and application revocations carried out by the platform; role mining (Identity → Role mining) drafts bundles from observed access as proposals, which a human accepts through the ordinary access-request flow — it never applies one on its own. Produce the review export; that is the artefact.
Evidence that a subject erasure completedThe workflow records a completed request and deletes nothing. Describe your manual process instead; do not offer the request record as evidence of deletion.
A cryptographically signed evidence exportThe bundle carries a SHA-256 integrity hash and stamping writes that hash into the audit chain. That is tamper-evidence with a recorded chain of custody. It is not a signature a third party can verify without us, and must not be described as one.
An immutable off-database archive of the audit trailWrite-once export to object storage is not implemented, so there is no second independent copy outside the database. If your policy requires one, record it as a gap.
Per-section status in the evidence bundleA section that failed to load and a section that is genuinely empty are not currently distinguishable. If a reviewer needs certainty about a specific empty section, regenerate the bundle and see whether it stays empty.
Proof that data older than the retention period has been deletedIt has not been. Retention is a search-window clamp, not a purge. Answer the question that was asked, in those terms.

What to read next

  1. The evidence bundle: what an auditor gets — the single artefact most of these requests are answered with.
  2. Access reviews and certification — the one row with no product answer, and how to cover it.
  3. Verifying the audit chain — before you make any claim about tamper-evidence.

Was this article wrong?

If a procedure here does not match what you see, or a limit we described has changed, tell us and we will fix the page. Email us about this article, or see how to get help if you need an answer rather than a correction.

Read next

Everything in compliance evidence