IT Documentation for NZ Businesses

IT documentation is the maintained record of the systems your business uses, how they connect, who is responsible for them and how authorised people support and recover them. It identifies where sensitive access information is held without copying secrets into ordinary documents.

 

One person set up your systems. They know which accounts hold administrator rights, why a firewall rule exists and which supplier to call when the internet drops. When they leave or are unavailable, someone else has to work all of that out again, sometimes while a problem is already affecting staff.

This guide gives owners and managers a practical checklist for IT documentation: what the records should contain, who controls and maintains them, how to keep them current and reachable, and how to check that another authorised person could use them.

What is IT documentation?

IT documentation records how your technology is put together and supported: the systems and devices, how they connect, who owns each account and service, how important settings were chosen, how backups work and how routine tasks are done. Its job is to let an appropriately skilled, authorised person understand the environment without relying on one person’s memory.

Good records reduce the time spent rediscovering how things work during support, changes and handovers. Their value still depends on accuracy, available access, supplier help and the skills of the person using them. Documentation does not replace backups, recovery testing or a planned handover.

It also differs from an IT assessment. An assessment reviews the environment and reports findings at a point in time; documentation is maintained as the environment changes, and assessment findings can help improve it.

What should IT documentation include?

Use this checklist to see what your records cover today. It describes the records to keep, not a request to publish them anywhere.

Record What to capture
Systems and assets Critical applications, devices, locations, owners, suppliers and dependencies.
Connectivity Internet services, network layout, device roles and important site connections.
Accounts and access Tenant and domain control, named administrators, access approvals and vault references.
Licences and suppliers Subscriptions, renewal dates, support contacts and responsibility for each service.
Configuration Relevant settings, why they exist, change history and protected configuration copies.
Backup and recovery Covered systems and exclusions, retention, restore instructions, dependencies and the latest relevant test.
Routine work Instructions for recurring tasks, with permissions, approvals and escalation contacts.

Each record needs an owner and dates for its last update and verification. Note gaps or assumptions so the next person knows what still needs checking. Device age and replacement timing can link to your hardware lifecycle planning, and joiner and leaver steps to your employee IT onboarding process.

Six areas of IT documentation: systems and assets, connectivity, access and licensing, configuration, backup and recovery, and routine procedures, with secrets held in a separate vault

The main areas of IT documentation. Passwords, recovery codes and private keys stay in a separate secure vault that the records point to.

Keep records separate from secrets

Ordinary documentation should identify account ownership, the access each role needs and where secrets are held. Store passwords, recovery codes and private keys in an access-controlled vault with authorised users and a recovery arrangement; our guide to password managers covers the options. Configuration exports can contain secrets too, so protect them rather than attaching them to a widely shared checklist.

Records that include staff or customer information need proportionate access controls. Information privacy principle 5 requires reasonable security safeguards for personal information; a documentation folder on its own does not show compliance.

Who controls the records and who maintains them?

Your business needs control of the information and access arrangements required to support its systems. A managed IT provider or internal team can maintain the technical records, with a business contact accountable for completeness.

Business accountability, technical maintenance, ownership of the documentation platform and contractual handover are different questions. Agree in your contract which customer-specific records and access information are supplied, in what format and when, and what remains part of a provider’s own platform or methods. Our guide to switching IT providers covers the handover sequence.

Staff, suppliers and other providers can change systems too, so agree how those changes are reported to whoever maintains the records. Co-managed arrangements need a written split of responsibilities.

Keeping documentation current

Update affected records as part of each material change, including new systems, access changes and supplier changes, rather than saving them for a yearly tidy-up. Then verify records on a cycle that suits how critical each system is and how frequently it changes.

Show the owner, last-updated date, last-verified date and known gaps on each record. An updated file date alone does not prove the contents were checked, and an unverified record presented as current can mislead the next person who relies on it. Flag uncertainty openly instead.

Insurers and auditors sometimes ask what systems and data a business holds. Records can help answer those questions, but they do not decide an insurance claim or guarantee compliance; requirements depend on the policy and circumstances.

Accessing records when systems are unavailable

A record is useful only if authorised people can reach it when needed. If email, sign-in or the documentation platform is unavailable, there needs to be another protected route to essential contacts, access instructions and recovery steps.

Decide who may use that route, keep it current and check access before an incident. Avoid an emergency copy that exposes every secret, and make sure it does not depend on the same systems it explains how to recover.

The New Zealand NCSC lists documentation, manuals and configuration among the data to include when you implement and test backups. Detailed recovery priorities belong in your backup and recovery plan.

How to check your documentation is usable

Choose one critical system and ask an authorised person who did not write its records to explain its owner, dependencies, support contact and access route. Walk through the recovery instructions without making disruptive changes. Record the gaps and assign them for correction.

Example IT documentation record with owner, maintainer, update and verification dates, known gaps and a vault reference, beside a four-step usability check

Illustrative example of a record and a usability check. A walkthrough checks the instructions; it does not replace a restore test.

Repeat the check for other critical systems over time. Each walkthrough shows where the records are clear, where they rely on assumptions and where access would be needed that the reader does not have.

Common IT documentation mistakes

  • Writing it once. Records created in a single effort and not updated afterwards drift away from the real environment while people keep trusting them.
  • Mixing records and secrets. Passwords in spreadsheets, diagrams or email attachments expose accounts; keep them in the vault and reference them.
  • No owner or dates. Without an accountable owner and verification dates, nobody knows which records can be relied on.
  • Only reachable from the systems it describes. If the records sit behind the same sign-in that has failed, they cannot help with recovery.
  • Excess detail. Capture what an authorised person needs to support and recover a system, rather than detail nobody can keep current.

How to start documenting a small business

Start with critical systems, responsible contacts, access arrangements and backup information. Capture known gaps and assign owners, then add dependencies and operating instructions. Use the records in normal support work and check that another authorised person can understand them.

Exodesk maintains documentation as part of our managed IT services, with a named contact at your business accountable for completeness. Exodesk has supported New Zealand businesses since 1989. Today, our Christchurch and Dunedin teams support businesses nationwide.

NEXT STEP

Could someone else support your business from today’s records?

Start with one critical system and find the gaps. Exodesk maintains documentation as part of managed IT support, agreed around your systems and responsibilities.

Frequently Asked Questions

What is IT documentation?

It is the maintained record of your systems, connections, ownership, support arrangements and operating instructions. It helps authorised people understand and support the environment, with references to secure access information rather than passwords copied into ordinary documents.

Why is IT documentation important?

It reduces reliance on the memory of one person and the time spent rediscovering how systems work. That helps support, changes and handovers. Its value depends on accurate records, suitable skills and available access; it does not guarantee uninterrupted operations.

What should IT documentation include?

Include system and asset records, connectivity, account ownership, licences, suppliers, relevant configuration, backup and recovery information, and recurring procedures. Identify dependencies and known gaps. Each record should have an owner and dates showing when it was updated and verified.

Who should control our IT documentation?

The business should retain control of the information and access arrangements needed for its systems. Agree access, exports and handover with your provider. Customer-specific records, the documentation platform and the internal methods of a provider are different things, so confirm the contractual arrangements.

Who maintains the records?

The internal IT team or provider responsible for the systems can maintain technical records. Name a business contact accountable for completeness, and agree how staff, suppliers and other providers report changes. Co-managed arrangements need a clear division of responsibilities.

How often should IT documentation be updated?

Update affected records after material changes and verify them on an agreed cycle. The frequency depends on how critical the systems are and how frequently they change. An updated file date alone does not prove that its contents have been checked.

Where should passwords and recovery codes be kept?

Use an approved, access-controlled vault with suitable recovery arrangements. Documentation can identify the account owner and vault reference. Keep secrets out of ordinary checklists, diagrams and email attachments, and restrict sensitive configuration copies too.

How do we access documentation during an outage?

Agree a protected alternative route to essential records if normal sign-in, email or the platform is unavailable. Identify who can use it, keep it current and check access. It should not rely entirely on the same systems it describes how to recover.

Is IT documentation the same as an assessment?

No. An assessment reviews the environment and identifies findings at a point in time. Documentation records how the environment works and is maintained as it changes. Findings can help improve the records, but neither guarantees that all information is current.

How do we start documenting a small business?

Start with critical systems, responsible contacts, access arrangements and backup information. Capture known gaps and assign owners, then add dependencies and operating instructions. Use the records in normal support work and check that another authorised person can understand them.

Contact us or call 0800 396 337 to talk about how documentation fits your support arrangement.

Start typing and press Enter to search

AI acceptable use policy: flat vector of a central policy document guiding staff using AI tools within safe boundaries.Supply chain security: illustrative map of a business connected to its suppliers, with one supplier incident highlighted. Call Us Now