The Operating Standard
Most IT providers describe what they do. Very few show you what you will actually receive. This page is the operational record set IT KORR produces — what each artifact contains, when it is produced, and why it matters to an insurer, an auditor, or a customer running a security review on you.
It is published so you can inspect it before signing anything — and so you can ask any provider, including this one, the questions at the bottom of this page.
Why This Is Published
Documentation is invisible until the moment it is expensive
Weak documentation does not announce itself. An environment runs, tickets close, and the absence of records costs nothing — right up until one of four things happens: an auditor or customer asks for an asset inventory, a cyber-insurance renewal asks for evidence rather than assurances, the person who knew how everything worked leaves, or the organisation decides to change provider.
At that point the question is never “will the provider hand the documentation over.” It is whether the documentation exists at all. A provider that never produced it cannot hand over what it does not have, and the reconstruction lands on the client under deadline.
Everything below is a process commitment, not a performance claim. It describes what records exist and when they are produced. It deliberately contains no metrics — no response times, no satisfaction scores, no uptime figures — because IT KORR does not publish numbers it cannot evidence.
The Record Set
Fourteen artifacts, in five domains
Scope is agreed per engagement — a co-managed engagement produces a different record set than a fully managed one. What does not vary is that the scope is written down before work begins.
Environment of record
Nobody can govern, recover, or audit an environment that is not written down. This is the layer everything else references.
Asset and environment inventory
Established at onboarding; maintained as changes occur.
What it contains
Endpoints, servers, network devices, cloud subscriptions and SaaS tenants — each with owner, location, lifecycle status and support state.
Why ask for it
This is the artifact insurers, auditors and customer security reviewers ask for first, and the one most organisations cannot produce.
Network documentation
Established at onboarding; updated with every network change.
What it contains
Topology, addressing, segmentation and VLAN intent, firewall rule purpose, internet and inter-site connectivity, and the reasoning behind the design.
Why ask for it
A diagram without design intent tells you what exists but not what is safe to change.
System ownership register
Reviewed at each operational review.
What it contains
Which system, which business owner, which technical owner, which vendor, and who approves change.
Why ask for it
When ownership is undefined, decisions stall and nobody is accountable for the risk a system carries.
Access and change
The two questions every audit and every incident investigation reduces to: who had access, and what changed.
Privileged access record
Maintained continuously; formally reviewed on a defined cycle.
What it contains
Administrative accounts by system, who holds them, why that access is required, break-glass account location, and what is time-bound rather than standing.
Why ask for it
Standing administrative access nobody can justify is the most common finding in an identity review — and the hardest to reconstruct later.
Access review record
On a defined cycle agreed per engagement.
What it contains
Review date, scope, reviewer, accounts examined, decisions reached, and the changes actually made as a result.
Why ask for it
A review that produced no record is indistinguishable from a review that never happened. Auditors treat them identically.
Change record
Per change.
What it contains
What changed, who approved it, when it was applied, the reason, the expected effect, and the rollback position.
Why ask for it
Each individual change is usually defensible. The accumulated state a year later is what nobody can explain without records.
Resilience evidence
A backup job reporting success is a status message, not evidence of recoverability.
Backup coverage status
Monitored continuously; reported on a defined cycle.
What it contains
What is protected, what is deliberately excluded and why, retention against the stated recovery objective, and where Microsoft 365 data sits in that picture.
Why ask for it
Coverage gaps are almost always in the systems nobody listed, not the systems being monitored.
Recovery test record
On a defined test cycle agreed per engagement.
What it contains
Date, system tested, method, what was actually restored, elapsed time, outcome, and anything that did not work as expected.
Why ask for it
Cyber-insurance applications increasingly ask for the date of the last successful restore test. An undated assurance is not an answer.
Security posture and currency
Controls that exist but cannot be evidenced are, for audit and underwriting purposes, controls that do not exist.
Patch and currency reporting
Continuous operations; reported on a defined cycle.
What it contains
Patch state by system class, exceptions with justification and review date, firmware lifecycle position, and end-of-support exposure.
Why ask for it
Deferred patching is a legitimate operational decision. An undocumented deferral is an unmanaged risk.
Security control baseline
Established at onboarding; reviewed on a defined cycle.
What it contains
The configured state of identity controls, Conditional Access, MFA enforcement scope, endpoint protection and email security — with deviations recorded.
Why ask for it
Configuration drifts quietly. A recorded baseline is what makes drift visible rather than discovered during an incident.
Vendor and third-party inventory
Maintained; reviewed on a defined cycle.
What it contains
Vendors with access to systems or data, what each can reach, contractual data-handling position, and review status.
Why ask for it
Customer security questionnaires now routinely ask about subservice organisations. This is the artifact that answers them.
Governance and review
The records that turn operations into something leadership can see and an auditor can follow.
Risk register
Reviewed at each operational review.
What it contains
Known operational and security risks, owner, current treatment, accepted risks with the reason for acceptance, and review date.
Why ask for it
An accepted risk documented with reasoning is a governance position. The same risk undocumented is an oversight.
Operational review record
On a defined review cycle.
What it contains
Environment state, work completed, open items, risk changes, lifecycle and budget implications, and decisions taken.
Why ask for it
This is the difference between a provider that reports activity and one that reports the state of your environment.
Incident documentation
Per incident.
What it contains
What happened, detection point, actions taken, resolution, contributing cause, and what changed afterwards to prevent recurrence.
Why ask for it
Without a contributing-cause record, the same incident recurs and is handled as if it were new.
Audit and questionnaire evidence
On request.
What it contains
The above artifacts assembled and mapped against the specific framework or customer questionnaire in scope, with gaps stated rather than glossed.
Why ask for it
Most organisations assemble this reactively under deadline. Produced continuously, it is a retrieval exercise rather than a reconstruction.
Worked Example
What a record actually looks like
A register of artifact names is still an assertion. These are the field structures behind two of the artifacts above — the two most often asked for as evidence and least often producible on request.
Recovery test record
The record a cyber-insurance application is asking for when it asks for the date of your last successful restore test.
- Test date
- The date the restore was actually performed — not the date it was scheduled.
- System and data scope
- Precisely what was restored, and from which backup set.
- Restore method
- Full, file-level, or workload recovery, and to what target.
- Recovery point achieved
- How much data loss the restore represents, against the stated objective.
- Elapsed time
- How long the restore actually took, against the stated objective.
- Verification
- How success was confirmed — the system opened, the data was checked, by whom.
- Exceptions
- Anything that did not work as expected, and whether it was resolved or carried forward.
- Performed by
- A named person, so the record is attributable.
Access review record
The record that distinguishes a review that happened from a review that was intended.
- Review date and cycle
- When, and which scheduled cycle it satisfies.
- Scope
- Which systems and which account classes were examined.
- Reviewer
- Named, and whether they are independent of the accounts under review.
- Accounts examined
- Count and classification — standing administrative, time-bound, service, guest, dormant.
- Findings
- What was identified: orphaned accounts, unjustified standing access, stale guests.
- Decisions
- For each finding — removed, reduced, time-bound, or retained with a stated reason.
- Changes applied
- What was actually changed, and when. A decision without an applied change is an open item, not a closure.
- Carried forward
- Anything unresolved, with an owner and a date.
Use This On Us
Eight questions worth asking any IT provider
Including IT KORR. A provider that cannot answer these concretely is describing intentions rather than operations — and the answers are far more diagnostic than a capability list or a certification badge.
Show me the asset inventory for an environment you currently run. Redact the client — I want to see the shape and the fields, not their data.
What was the date of the last documented recovery test you performed, and what does that record contain?
Who holds the Global Administrator accounts in the environments you manage, and does the client hold their own?
If we ended the relationship, what documentation would we leave with, in what format, and is that written into the agreement?
Show me a change record. I want to see whether the reason and the rollback position are captured, not just the action.
When a customer sends us a security questionnaire, what can you produce, and what would we still have to answer ourselves?
Which of these records exist today for your current clients, and which are produced only on request?
Who owns the documentation platform — you or us — and what happens to the records if we move provider?
If a provider answers question four with anything other than a clear description of what you leave with and where that is written down, treat it as the answer. Absent an explicit transition-assistance clause, an outgoing provider is generally under no obligation to assist a departing client at all.
Stated Plainly
What this standard is not
- Not a compliance certification. IT KORR produces IT controls and evidence; attestation and audit opinion rest with your auditor. IT KORR holds no certifications of its own.
- Not a security operations centre. These records do not constitute 24x7 threat monitoring, managed detection and response, or continuous security surveillance — none of which IT KORR provides.
- Not a service-level commitment. This page describes which records exist and when they are produced. It makes no claim about response times, resolution times, or availability.
- Not a fixed package. The record set in scope is agreed per engagement and written down before work begins, rather than promised in full and delivered in part.
- Not a substitute for your own governance. These artifacts inform decisions; the decisions, and the risk acceptance behind them, remain yours.
FAQ
Common Questions
Why publish this instead of keeping it as a sales document?
Because a standard you can only see after signing is not a standard you can evaluate. The purpose of this page is to let you compare IT KORR against any other provider on something more substantive than a capability list — including by asking IT KORR the same questions you would ask anyone else.
Is every artifact on this page produced for every engagement?
No, and a provider claiming otherwise is overstating. Scope is agreed per engagement — a co-managed engagement where your internal team owns change management produces a different record set than a fully managed one. What does not vary is that the scope is written down at the start, so there is no ambiguity about which records exist.
Who owns the documentation?
You do. Records are produced to a standard and held by you, in a form that remains usable if the engagement ends. Documentation that only exists inside a provider-owned platform is a dependency, not a deliverable — and it is the reason some organisations discover at exit that they are starting their documentation from zero.
Does this mean IT KORR can make us compliant with SOC 2 or HIPAA?
No. IT KORR produces the IT-side controls and evidence that sit underneath a compliance position — access records, change history, patch and recovery evidence, configuration baselines, vendor inventory. The compliance position itself, and any attestation or audit opinion, rests with your organisation, your auditor and your counsel. IT KORR holds no certifications of its own and does not perform audits.
How is this different from the reports most providers already send?
Most operational reporting answers "what did you do." These artifacts answer "what is the state of the environment, who can change it, and can you prove it." The second set is what an insurer, an auditor or a prospective customer actually asks for — and it is the set most organisations cannot produce on request.
Can you work to our existing documentation standard instead?
Yes, where one exists. If your organisation already has a documentation standard — because of a parent company, a framework you report against, or a prior internal programme — the sensible approach is to meet it rather than impose a second one. Where no standard exists, this is the starting point.
Related
The service that produces and maintains these records as an ongoing operation.
How these artifacts map to the frameworks your customers and insurers ask about.
How record-keeping responsibility splits when you have an internal IT team.
How evidence is generated, retained and retrieved — the concept behind these artifacts.
The operating model these records are produced inside.
Check which of these records your current environment can actually produce today.
Inspect Before You Commit
Review this standard against your current environment
Bring your current provider's documentation — or the absence of it — and we will walk through which of these records exist today and which would need to be built. No commitment, and you keep the findings either way.
We respond within one business day.