Shared Holiday Home Guest Access Expiry Checklist

A shared holiday home guest access expiry checklist should confirm that every temporary route created for one approved stay has reached its intended end state. Check physical entry, digital lock access, alarm or gate access, guest documents, shared folders, messages, property devices and support contacts separately. Record the source, expected end, observed state, exception, action owner and verification date without copying a live code or sensitive guest detail.

Do not ask a former guest to test whether access still works. Do not assume deleting one message recalls its copies, or that ending a booking automatically closes a lock, building, document or communication route. Use the current instructions for the actual property, provider and governing arrangement. This checklist coordinates an already-authorised close-out; it does not decide a guest's rights, create entry authority, replace safety arrangements or provide legal advice.

Keep Preparation, the Stay and Expiry Separate

Guest access crosses several records, but each record should keep one job.

The guest-ready guide owns the arrival standard. The key and access register owns lasting access methods. The changeover handover record owns the overall result between stays. This page owns the narrow close-out of temporary routes created for one guest stay.

Copy This Guest Access Close-Out

Create one close-out for each approved stay. Use stable references such as STAY-042 and ACCESS-07; do not use a guest's name as the record ID when a less identifying reference works.

Stay reference:
Approved arrival and departure window:
Close-out owner and backup:
Source that defines the access window:

Temporary route ID and category:
Purpose and permitted boundary:
Issuer or administrator role:
Intended start and end:
Expected end state:
Current authoritative source or system:
Observed state and observation time:
Verification method that does not expose or retest the credential:
Evidence reference and restricted location:
Residual copy, device, message or physical-item risk:
Exception and operational effect:
Action owner and due point:
Escalation source:
Result: verified ended / returned / restricted / still active / unknown / disputed:
Independent verifier where appropriate:

Ordinary owner or emergency route confirmed separately:
Changeover record updated:
Standing access register updated if the method changed:
Minimal record retained under the group's approved rule:
Closed by and date:

Use one route per row. A door code, building fob, parking permit, shared folder and help-chat membership may all relate to the same stay, but they can have different administrators and end states.

Map Every Temporary Route

Start from what the group actually issued, not from a generic smart-home list. Review the approved guest information, access register, provider account, building process and changeover record. Common routes include:

• a physical key, fob, card, parking permit or lockbox item;
• a guest passcode, time schedule, app invitation or building-system permission;
• an alarm, gate, garage, lift or shared-facility route;
• a guest-only web page, shared folder, QR code or document link;
• a messaging group, support channel or named property contact route;
• a property tablet, television profile, network guest mode or other shared device; and
• an emergency or backup route issued specifically for that stay.

Do not expand the review into a search of a guest's personal phone, email, account or movements. Record only the group's own source, the route it administered, and the minimum evidence needed to close the task. If another party controls the route, record the verified contact and acknowledgement rather than claiming the group changed it.

Close the Stay in Seven Steps

1. Freeze the intended boundary

Record the approved stay reference, property, arrival and departure window, issuer, and source that defined the guest access. If the stay was extended or departure changed, update the authorised source before closing anything. A calendar edit, text message and building instruction can disagree; one responsible person must resolve the current approved boundary through the group's valid process.

Keep rights questions outside this operational checklist. If access is disputed, a person remains lawfully entitled to enter, a tenancy or hospitality rule may apply, or an urgent welfare or safety issue exists, mark the row disputed and use appropriate property-specific, provider and qualified advice. Do not use a technical control to decide the dispute.

2. Compare intended expiry with the live source

Open the current administrator or provider view for each route. Compare the intended end with what the authoritative source shows now. A planned end date in a message is not proof that the lock, folder or building system applied it.

Google's current guidance for compatible locks illustrates why the provider view matters: guest passcodes can be indefinite or scheduled, and an administrator can edit the schedule or revoke the passcode. That is one product example, not a universal lock rule. Follow the instructions for the actual model and system. See Google Home's current lock-control guidance.

Do not reveal the code in the close-out. Record the route ID, administrator observation, time and end state. If the system is offline, stale or ambiguous, write unknown and use the provider's official recovery or support route.

3. Return physical items without exposing the backup

For keys, fobs, cards and permits, confirm the expected return point, observed return, item condition and next custodian. Use a sealed or controlled handoff where the item itself could grant entry. Never write a spare-key location into the guest record.

A returned key is not proof that no copy exists. Equally, the possibility of a copy does not justify an unsupported claim that access remains active. Record the known fact, the group's approved risk decision, and any authorised rekey, provider or insurer review. Do not photograph key cuts, identity documents or unnecessary personal possessions as routine evidence.

4. End digital and document routes at their source

Remove or expire the specific guest invitation, folder audience, property-guide share, message membership or temporary profile through the system that owns it. Check nested folders, inherited permissions and links only where the group administers them and the approved close-out requires it.

The UK National Cyber Security Centre's organisational guidance says access rights should be reviewed and technically removed when no longer required. That is useful security practice, not a statement of private-property law or a promise that every copied file disappears. See the NCSC identity and access-control principle.

If a guide was sent as an attachment, ending the source share does not recall that attachment. Record the residual-copy limitation and remove secrets from guest documents in the first place. Rotate or replace a reusable detail only through the authorised property or provider process.

5. Verify without asking the former guest to try

Use an administrator status, access-list absence, provider acknowledgement, item return or another approved source-led check. Do not send a former guest a live link or ask them to attempt entry “just to make sure.” A failed attempt can create confusion or safety risk; a successful attempt unnecessarily exercises access the group intended to end.

Verification should answer a narrow question: does the current source show the intended end state? Record verified ended, returned, restricted, still active, unknown or disputed. Avoid absolute statements such as all access erased when copies, offline systems or third-party controls remain outside the evidence.

6. Protect ordinary and emergency access

Guest expiry should not disable the co-owners' ordinary route, a caretaker's current authority or an approved emergency process. Before a broad reset, identify dependencies: an alarm may share a keypad, a gate may use a building-managed directory, or a lock may rely on a property hub.

Confirm the ordinary route through its own approved test. Keep that result separate from the guest row so the checklist does not expose owner credentials. If a route supports fire safety, welfare, accessibility or emergency response, use the responsible local and professional source before changing it.

7. Close exceptions, then retain the minimum record

An exception needs an owner, due point and consequence. Examples include a missing fob, an offline lock, a building administrator awaiting instructions, an inherited folder permission, or an old guide containing a reusable detail. Link the exception to the correct incident, maintenance, provider or decision record instead of hiding it inside notes.

When every route is verified or assigned, update the changeover result. Update the standing access register only if a method, administrator, controlled-detail location or review trigger changed. Retain the minimum close-out evidence the group is validly entitled and needs to keep; do not preserve a permanent guest dossier by default.

Route-by-Route Completion Tests

Worked Example

Four siblings share a coastal cottage. Their approved stay STAY-042 used a scheduled lock passcode, one building parking permit, a guest welcome-book link and a temporary message group. The access register points to each controlled source without storing the passcode.

After departure, Morgan opens the current lock administrator view and records that the guest route shows expired at the scheduled time. The permit is back with its named custodian. The welcome-book audience no longer includes the guest address, but Morgan records that any earlier download cannot be recalled. The message group is closed after one broken-lamp report is moved to the maintenance workflow.

The changeover owner marks guest-access close-out complete. No one asks the guest to try the door, searches the guest's device, copies lock history into a shared note or states that every copy has been erased. The standing register remains unchanged because the underlying methods and administrators did not change.

Common Failure Modes

• One “access closed” checkbox: it hides different administrators and end states.
• A reusable code in the welcome message: deleting the message does not change the code.
• Testing through the former guest: it exercises the access being closed and produces ambiguous evidence.
• A broad reset without a dependency check: it can interrupt owner, caretaker, alarm or emergency routes.
• Screenshots full of names and codes: they duplicate sensitive material when a status and source reference would do.
• Treating return as certainty: a returned key is evidence of return, not proof about every possible copy.
• Deleting the history: it removes the handover trail without proving the live route ended.
• Using expiry to decide a rights dispute: technical administration cannot replace valid authority or qualified advice.

FAQ

Should every guest receive a unique access route?

Use the current provider and property process. Where the system supports a separate scheduled guest route, it can make the intended audience and end easier to verify. Do not promise that every lock supports it or change a property system without approval.

Should the checklist contain the guest's code?

No. Store only the access reference, purpose, administrator, intended window, observed state and controlled evidence location. Keep any live secret in the authorised system that needs it.

Is an automatic expiry enough?

Treat it as the intended control, then check the current authoritative source. Schedules may be edited, systems may be offline and different routes may not share one expiry.

Can co-owners keep access-history screenshots?

Only when they have a valid need and authority, and only with appropriate access, minimisation and retention controls. Routine close-out usually needs a result and source reference, not a copied movement history.

What if a key or fob is missing?

Record the item, known facts, operational effect and action owner. Follow the property's approved issuer, building, insurer, security and qualified-advice routes. Do not invent a universal rekey rule.

What if a guest needs access after departure?

Create a new, approved purpose and time boundary through the valid process. Do not silently extend the old route or leave it active “just in case.”

Does removing a shared link delete downloaded copies?

No. It changes the source permission; it does not prove that a recipient's earlier copy disappeared. Design guest documents so they do not contain reusable secrets or unnecessary personal information.

How long should the close-out record be kept?

Use the group's valid retention rule and any applicable property, provider, insurer and jurisdictional requirements. Keep the minimum evidence needed for the stated purpose, not a permanent guest profile by default.

Keep Guest Close-Outs Lightweight

Use the free guest welcome book generator to organise approved arrival, property-use and departure information without turning messages into the permanent source of truth. Then give each temporary access route a named administrator, intended end and source-led completion test.

Shared Holiday Homes can keep guest information, assigned close-out tasks, house documents and changeover work together for private co-owner groups. Start your free trial after the group has agreed who may issue and close each route.