Shared Holiday Home Co-Owner Access Removal Handover
A shared holiday home owner access removal checklist should show which already-authorised change is being implemented, every physical and digital route in scope, who may act in each source system, what was observed before and after the change, and which exceptions remain open. It must not contain keys, codes, passwords, recovery material, private links, identity documents, sensitive personal data, or instructions for bypassing a control.
Use one handover for one defined change affecting a family member, friend, sibling, trustee, entity representative, provider, guest, or other approved participant in a privately shared holiday home. The checklist coordinates implementation only. It does not decide whether someone has an ownership, occupancy, trustee, tenancy, company, contractual, privacy, or entry right; create authority; authorize force; settle a dispute; or replace qualified local advice.
The key and access register owns the standing map of property-entry methods. The document access review checklist owns a wider review of document audiences and sharing routes. The account access recovery handover owns restoring authorised access to one provider account. This handover owns the execution and verification of one removal that has already been authorised through the source that actually applies.
Copy This Owner Access Removal Checklist
Create one row per system or controlled physical route. Use safe labels and source references, never the access detail itself.
| Check | Record safely | Completion evidence | If unresolved |
|---|---|---|---|
| 1. Change scope | Property, person or role label, trigger, effective point, exclusions, handover owner, and verifier | A bounded list of routes exists before any change starts | Pause expansion and ask the authorised source owner |
| 2. Authority source | Decision or instruction reference, applicable governing source, authorised actor, date confirmed, and limits | The actor can point to the current source that permits this exact action | Mark authority review required; do not infer a right from an internal role |
| 3. Pre-change state | System or item label, access class, administrator, source checked, observation time, and evidence location | An authorised observer recorded the actual source state without copying secrets | Mark state unverified rather than guessing |
| 4. Removal action | Return, disable, revoke, remove, transfer, rotate through provider, preserve, or not applicable; actor and action time | The source system or controlled physical process confirms the action | Record blocked, disputed, provider pending, or professional review due |
| 5. Continuity | Remaining authorised administrator, backup route, records or property functions affected, and approved next owner | Needed access remains with the correct authorised people without credential sharing | Use the provider, governing, recovery, emergency, or qualified route |
| 6. Verification | Verifier, source checked, result, date and time, residual routes, and evidence reference | An authorised view shows the intended state; no removed person is asked to test it | Keep the route open as unverified |
| 7. Record handoffs | Registers, documents, contacts, tasks, stays, provider jobs, devices, and review dates that must change | Every destination record has an owner and a source-supported state | Create a named exception instead of writing “all access removed” |
| 8. Close-out | Completed routes, exclusions, open exceptions, next action, next review, and approver | Each route is verified, not applicable, or open with a responsible owner | Close as completed with exceptions, not fully complete |
The checklist is a coordination record, not the control. Completion evidence must come from the lock administrator, key custodian, storage platform, account provider, device manager, building manager, controlled document source, or other system that actually governs the route.
Confirm the Decision Before Changing Access
“Remove access” can conceal several different decisions. A person may stop administering a lock but retain an approved entry method. They may leave a property-service role but remain a co-owner. A guest link may end while an owner-only document audience remains. A trustee, executor, entity representative, tenant, lender, insurer, court, provider, or governing agreement may impose a separate process.
Before implementation, record:
- the exact person, role, property, systems, and access classes affected;
- the event that triggered the instruction;
- the source that authorises each change and the person permitted to act;
- the effective date or event, including whether actions must be sequenced;
- exclusions, preserved access, evidence, property, or records;
- any notification, return, retention, dispute, safety, or professional requirement; and
- who will verify the result independently where appropriate.
Do not turn a message, task assignment, family title, payment history, booking, administrator badge, or possession of a key into authority it does not create. If the instruction is incomplete, disputed, unsafe, or inconsistent with a governing source, stop the affected action and route it to the qualified source. An urgent security response can run in parallel through the real provider, insurer, authority, emergency, or professional process.
Map Every Route Without Listing Secrets
An access change can span more than a front-door key and one app account. Build a system map from sources the group is already authorised to inspect.
| Route | Examples to check | Safe evidence | Boundary |
|---|---|---|---|
| Physical entry | Keys, fobs, cards, remotes, permits, gate or building credentials, approved spare custody | Item ID, custodian, return state, source, and verifier | Never record the key location or reusable code in a broad log |
| Property systems | Smart lock, alarm, intercom, gate, garage, heating, cameras, network, monitoring, or caretaker portal | System label, role removed, administrator observation, and provider reference | Use the manufacturer's or provider's authorised controls |
| Documents and communication | Folders, individual shares, groups, links, calendars, mailing lists, messaging spaces, and printed packs | Audience or group label, level, action, and actual source result | Removing access is not permission to delete documents or history |
| Service accounts | Utilities, internet, insurer, association, waste, maintenance, payment, booking, or supplier accounts | Account label, recognised role, provider route, change state, and acknowledgement | The provider decides its identity, authority, recovery, and session controls |
| Devices and integrations | Shared tablets, issued devices, browser sessions, apps, connected services, automations, backups, and tokens | Device or integration label, custody, administrator action, and source-confirmed state | Do not inspect, erase, track, or control a personal device without authority |
| Guest and provider routes | Arrival links, temporary access, work-order entry, cleaning packs, emergency sheets, and copied instructions | Audience, job or stay reference, expiry, source state, and replacement route | Do not claim every downloaded or forwarded copy has disappeared |
Use a stable route ID such as ENTRY-04, DOC-GROUP-02, or SERVICE-07. Keep passwords, codes, passkeys, recovery material, private URLs, personal identifiers, full account numbers, spare locations, and empty-home dates inside the approved restricted system designed for them.
Use a Source-Led Removal Sequence
1. Freeze the scope and evidence cut-off
Record the time the handover begins and the systems included. If the instruction changes later, preserve the earlier state and add a new authorised event. Do not silently widen one removal to every system connected with a person.
2. Protect continuity before removing an administrator
Confirm that each needed system has an authorised remaining administrator, provider-recognised contact, controlled recovery route, and appropriate record owner. Transfer or preserve required documents and property information through the source process before an administrator role ends. Never solve continuity by copying one person's credentials to another.
3. Record the actual pre-change state
An authorised observer should check the current holder, member, administrator, group, session, device, integration, link, or physical custody state. Record the observation and evidence reference without capturing more personal or security information than necessary.
The UK National Cyber Security Centre's identity and access guidance is written for organisations and essential services, not private co-owned homes. Its narrow operational principle is still useful: access should be documented, periodically reviewed, and technically removed when it is no longer required after a role change. See the NCSC identity and access control guidance. That principle does not decide when a co-owner's access is legally no longer required.
4. Carry out each approved action at its source
Return a numbered key through the approved custody route. Remove a named member through the storage platform. End a temporary code through the lock provider. Change a service-account role through the provider. Revoke an integration through the system administrator. Follow the manufacturer, building, contract, governing, privacy, retention, safety, and qualified sources that apply.
Use precise states: return requested, returned unverified, provider pending, role removed, session review required, replacement route approved, blocked by dispute, or verified. Avoid done, locked out, or everything removed unless the relevant sources support that exact conclusion.
5. Separate credential rotation from access removal
A platform may remove one named account without changing a shared credential. Another system may require an authorised administrator to rotate a code or secret after a role change. Follow the provider or manufacturer process. The shared handover should record only rotation required, rotation completed by administrator, and the verification result—not the old or new value.
6. Verify through an authorised view
Ask an authorised verifier to inspect the source after the change. They might confirm that a returned key matches its inventory ID, a member no longer appears in a group, a temporary route is disabled, an administrator list is correct, or a provider has acknowledged a role change.
Do not ask the affected person to attempt entry or log in. Do not use their device, identity, account, saved session, or copied credential to test the result. A source-confirmed removal also cannot prove that every earlier download, screenshot, forwarded message, duplicate key, or personal note has been recovered.
7. Reconcile the connected records
Update the access register, document audience, contact route, service-account map, current guest or provider instructions, task ownership, device custody, admin calendar, and decision record where each source requires it. Use the emergency information sheet tool only to prepare current, approved, non-secret emergency information; it does not grant or remove access.
8. Close with exceptions visible
Close only when every in-scope route is verified, not applicable, or open exception with an owner and next route. Keep uncertainty explicit. If one building fob is awaiting management confirmation and one old folder audience needs professional review, the result is completed with two exceptions.
Route Exceptions Instead of Improvising
Common exceptions include:
- a key, fob, remote, card, or issued device is not returned;
- the only administrator is the person whose role is changing;
- a provider does not recognise the group's internal instruction;
- access is inherited through a group, integration, or another account;
- a physical or digital route cannot be identified safely;
- the person disputes the instruction or the authority source is unclear;
- a document, message, log, or device may be subject to retention or evidence requirements;
- a shared or personal device contains mixed information;
- an old guest or provider link may have been copied outside the system; or
- the property has an immediate security, safety, welfare, or service risk.
For each exception, record the observation, affected route ID, source checked, current operational effect without exaggeration, responsible owner, approved next route, due date, and destination record. Use the real building manager, provider, manufacturer, insurer, privacy, governing, dispute, emergency, law-enforcement, or qualified professional process as applicable. Never force entry, seize or search a personal device, impersonate another user, destroy evidence, or publish sensitive details.
Fictional Example: One Approved Role Change
Four siblings privately share a cottage. After an already-documented ownership and trustee process, their qualified sources confirm that Morgan's property-administrator role ends on 30 September. The group uses handover ACCESS-REMOVE-004. The record does not interpret the governing documents or copy the underlying private material; it references the approved instruction and its scope.
The access register shows one numbered gate fob assigned to Morgan, ordinary property access that the governing source says remains in place for now, and an administrator role in the smart-lock system that must end. The group therefore requests return of the fob and removes the administrator role, but it does not disable the preserved ordinary access. A second authorised administrator checks the provider console and records the result without copying codes.
Morgan also appears in an owner-document group and a maintenance-provider mailing list. The instruction covers the provider list but not the owner-document audience, which has a separate review pending. Jamie removes the provider-list membership at its source. Priya records the document route as excluded—authority review open; she does not treat the administrator change as permission to remove or delete ownership files.
The fob is returned and matched to its inventory ID. The building manager has not yet confirmed its system state, so that route remains returned—verification pending. The handover closes as completed with one exception and names the person responsible for following up. No one asks Morgan to test a door, reveal a code, hand over a personal device, or surrender access outside the approved scope.
This fictional example illustrates record boundaries only. It does not establish anyone's rights, duties, authority, notice, retention, security, privacy, dispute, or legal outcome.
FAQ
Can a checklist decide when a former co-owner should lose access?
No. Use the applicable ownership, trust, estate, company, tenancy, contract, court, insurer, lender, provider, privacy, and local legal sources. This checklist starts only after the exact change and authorised actor are established.
Should every access route be removed at the same time?
Not automatically. Timing and sequence can differ by route, source, safety need, administrator continuity, notification requirement, and preserved right. Record the effective point and evidence for each route.
Is changing the door code enough?
No. Check only the in-scope physical items, property systems, document audiences, accounts, devices, integrations, guest routes, and provider routes. Conversely, do not change unrelated routes merely because one code changed.
Should the group save old passwords or codes as evidence?
No. Keep secrets in the approved restricted system, if retention is authorised and required at all. The handover needs a safe action label, source, actor, time, evidence reference, and verification state—not the credential.
What if the affected person still has an entitled role?
Do not infer that all access should end. Preserve the distinction between administrator, ordinary owner, trustee, guest, provider, document, account, and physical access. Pause any disputed or unclear action and use the governing and qualified route.
What if a key or device is not returned?
Record the item ID, request state, source, operational effect, owner, and approved escalation route. Do not confront, search, track, enter, or remotely erase a personal device without authority. Follow the applicable building, provider, insurer, security, privacy, dispute, and professional process.
Can Shared Holiday Homes revoke locks or external accounts?
No. Shared Holiday Homes helps approved groups coordinate property information, supporting house documents, and assigned tasks. It does not decide rights, validate authority, control locks, revoke external accounts, store credentials, or replace provider and professional systems.
What proves the handover is complete?
Every in-scope route must have a source-confirmed state, verifier, evidence reference, and destination-record update. Any unresolved route remains an exception with an owner and next action.
Keep the Access Change Bounded and Reviewable
A useful handover starts with authority already established, changes each route at its real source, protects continuity, records no secrets, verifies the result, and keeps exceptions visible. It should leave the group with an auditable implementation record—not an unsupported claim that a person's rights ended.
Shared Holiday Homes can keep approved property information, supporting documents, and follow-up tasks together for a private co-owner group. It remains separate from locks, external account controls, governing documents, and professional advice. Start your free trial to coordinate the agreed work without turning a shared task list into an access-control system.
