Who can retrieve the accepted work when its usual owner is absent? A small team needs an inventory of its working systems, clear access ownership and a recovery exercise that produces a record. Start with one important process and a safe test copy. This guide provides a working checklist; it does not certify a company's security or authorise changes to live accounts.
1. Inventory the systems the process needs
Follow one assignment from receipt to acceptance, using the handover model. List the systems that hold its request, agreed scope, working files and accepted result. Include the account used to administer each system and the person responsible for arranging access.
Write down what would stop if a system were unavailable. Separate the person who owns the business process from the administrator who can change permissions. Neither role should be inferred solely from who first bought the service or created the folder.
Scroll sideways to see every column.
| System record | What to enter | What to leave out |
|---|---|---|
| Service and purpose | System name and the business action it supports | Unverified claims about the supplier |
| Business owner | Person accountable for the process and its records | A team name with no accountable person |
| Access administrator | Person or authorised provider handling permissions | Passwords, tokens and recovery codes |
| Working data | Type of data, location and access requirement | Copies of customer personal data in a demonstration |
| Recovery arrangement | Backup location, responsible role and recovery procedure reference | An assumption that synchronisation guarantees recovery |
| Last review | Date, reviewer and unresolved issues | A blank field presented as confirmation |
Use role names for the example, then assign real responsible people in the private company record. The inventory is an index, not a place to concentrate secrets.
2. Map access to an actual role
Review who needs to read, change, approve and administer the records. Keep individual work accounts attributable to their users. Treat administrative access as a separate responsibility and document how it is granted and reviewed.
Check multi-factor authentication against the provider's current supported methods and the organisation's policy. Record the responsible role and the result of the check, without putting a secret or a recovery code into the inventory. Any change to a real authentication method needs the organisation's authorised administrator and its established procedure.
For a change of role or a departing colleague, identify who will transfer ownership of files and remove access when appropriate. Check shared links and provider access alongside the named user list. A disabled personal account does not by itself establish that every previously shared link is closed.
3. Define what must be recovered
Choose the information and service needed to resume the selected process. Record the acceptable age of recovered data and the time in which the business needs the process restored. These are requirements for planning and testing, not promises made by this guide or a cloud provider.
Identify where backups are kept, what is included, who checks failures and who can initiate recovery. Keep the recovery route available to the authorised people who need it during a service interruption. Confirm the provider's version history, retention and export arrangements from its current documentation or agreement.
Do not assume that a synchronised folder is a recoverable backup. Check the specific service's treatment of deletion, overwritten files and older versions. A copy existing somewhere and a tested route to an accepted business result are different pieces of evidence.
4. Run a safe, limited recovery exercise
The following is a fictional exercise with synthetic data. Create a test assignment and two test documents containing a recognisable reporting period and an expected result. Put the safe test copy through the documented backup and restore route. Restore into a separate test location, not over live working files.
Before starting, name the test owner, the person performing recovery and the person checking the result. Define the expected files and content, the starting condition and a stopping rule. If the exercise risks touching live records or changing real access unexpectedly, stop and involve the responsible administrator.
After restoration, check the expected file count, content and version. A successful operation message alone does not establish that the business information is complete. Record whether the reviewer can use the restored material for the intended next step. Do not delete a live file merely to demonstrate that recovery works.
5. Keep a recovery record with exceptions
Scroll sideways to see every column.
| Record field | Entry for your exercise |
|---|---|
| Test scope | Selected system and synthetic assignment; excluded live data |
| Expected result | File names, content and version that should be restored |
| People and authority | Owner, operator, reviewer and approved procedure |
| Backup reference | Copy or version used, with its timestamp |
| Start and finish | Observed times and the measurement boundary |
| Result check | Files found, content checked and reviewer decision |
| Exceptions | Missing data, failed step, unresolved access or delay |
| Follow-up | Responsible person, action and next test date |
A failed exercise is a result to retain. Distinguish a missing copy, an unusable restore method and an access problem, because their next actions differ. Do not mark all three as a generic “backup issue” and close the record without an owner.
6. Ask the provider concrete questions
Ask how authorised people obtain an export, which formats it includes and what information is outside that export. Confirm who can restore a prior version, what retention is agreed and which steps require provider support. Record the answer's date and the relevant documentation or agreement reference.
Review these arrangements before a change of supplier or integration. A working export is not automatically a working import into another system. Use synthetic data to check the intended transfer and preserve the original records until the responsible people accept the result.
7. Connect recovery to planned changes
The first-month workflow plan helps choose the process boundary. Before a limited automation trial, confirm the trial's permissions, recovery route and fallback owner. This checklist is a preparation step, not permission to alter production security controls.
The Estonian Information System Authority's 2025 guide covers inventory, justified access, multi-factor authentication, recovery planning and trial restores. The forms and synthetic exercise in this article are the publication's practical model built around those topics. They do not replace a complete risk assessment, supplier-specific instructions or applicable organisational requirements.
8. Sources and next action
- RIA: advice for organisations and enterprises.
- RIA: company cybersecurity quick guide, 2025, particularly the access, authentication and recovery sections. Sources checked 3 November 2026.
- Select one critical process, complete its system inventory without secrets and agree on a separate, synthetic recovery exercise with the authorised people.