Who Had Access, and When? Access Records for Remote Teams

When a client asks who had access to their work and when that access ended, the answer should come from a record, not from memory. Keep a record of every access change for your remote team, and decide now how long you need to keep it.

Remote teams that handle a client's data get asked about access sooner or later. It might be a quarterly review, a security questionnaire, or a single email after an agent leaves on bad terms. The question sounds simple. For many teams, answering it takes days.

The short answer

For every person on a client account, you should be able to show when they were given access, who made that change, when access was disabled and when the desktop was removed. Keep those records in one place, have a named administrator confirm each change with their own sign-in, and check how long Microsoft keeps its own logs by default. Depending on your licences that can be a week, a month or six months, which is often shorter than the period a client asks about.

The questions clients actually ask

• Who has access today? A current list of the people who can reach the client's systems or data.
• Who had access on a given date? Usually a date in the past, such as the start of an incident or the end of a contract.
• When was a leaver's access removed? The exact day and time, not "around the end of the month".
• Who approved the change? A named person in your organisation, not "IT".
• How do you know? The evidence behind each of the answers above.

Why the answer is usually scattered

In most small and mid-sized teams, access changes happen through whatever channel is quickest. A team leader messages the IT provider. Someone updates a spreadsheet, or forgets to. The provider closes a ticket. Each piece of the story lives somewhere different, and none of it was written with an auditor in mind.

Shared administrator accounts make it worse. If three people use the same admin login, the log can tell you that the account made a change, but not which person did. And when an outside provider holds the admin rights, your record of who changed what depends on their ticket history, not yours.

How long Microsoft keeps the records by default

Microsoft 365 does record activity, but not forever, and the default periods are shorter than many people assume.

• Microsoft Entra ID audit and sign-in logs are kept for seven days on Microsoft Entra ID Free and for 30 days on P1 or P2.
• Microsoft Purview Audit (Standard) keeps audit records for 180 days.
• Microsoft Purview Audit (Premium) keeps Microsoft Entra ID, Exchange, OneDrive and SharePoint records for one year by default, with longer retention available through retention policies and an add-on licence.

So a question asked in October about an agent who left in March may fall outside what your tenant still holds. If you need to answer for longer, Microsoft's guidance is to route the Entra logs to an Azure storage account through Azure Monitor, or to use Audit (Premium) where your licences include it. Decide this before the question arrives, not after.

What a usable access record contains

An access record is useful when someone outside your team can read it and reach the same answer you did. For each change, it should show:

1. Who the change was for. The member of staff by name, and the client account they work on.
2. What changed. Access given, disabled or removed.
3. When it happened. Date and time, in a stated time zone.
4. Who made it. A named administrator, signed in as themselves.
5. Why. A start date, a role change or a last working day, with a reference to the HR or ticket record where one exists.

Keep the list of people with current access alongside the record of changes. Clients usually ask for both: the list as it stands today, and the history behind it.

Where Seatvane fits

Seatvane is the portal we built for our managed Windows 365 Cloud PC service. Your own administrator gives staff a Cloud PC, watches it being set up, and disables or removes access when someone leaves. Every change is confirmed with that administrator's own Microsoft sign-in and recorded in an audit trail, so the person who makes a change and the person accountable for it are the same.

It is built for remote teams that handle sensitive data, such as healthcare providers and BPO companies, and billing is in pesos with official receipts. We suggest asking for a walkthrough of exactly what the audit trail shows, so you can check it against what your clients ask for.

Seatvane covers the Cloud PCs it manages. Access to other systems, such as a client's own applications or shared mailboxes, still needs its own record.

Frequently asked questions

How long does Microsoft 365 keep sign-in and audit logs?

Microsoft Entra ID keeps audit and sign-in logs for seven days on the free tier and 30 days with P1 or P2. Microsoft Purview Audit (Standard) keeps audit records for 180 days, and Audit (Premium) keeps Entra ID, Exchange, OneDrive and SharePoint records for one year by default.

Can we keep Microsoft Entra logs for longer?

Yes. Microsoft's guidance is to route them to an Azure storage account using Azure Monitor, or to use Microsoft Purview Audit (Premium) if your licences include it. Set this up before you need the records.

Is a spreadsheet of joiners and leavers enough?

It helps, but it shows what someone wrote down, not what actually changed. A record created at the moment of the change, by a named person signed in as themselves, carries more weight with a client.

Why should access changes use the administrator's own sign-in?

Because a log can only name the account that made a change. If the account is shared, or belongs to an outside provider, the record cannot say which person in your organisation was responsible.

Does Seatvane replace our other access records?

No. It records changes to the Cloud PCs it manages. Access to other systems still needs its own record and review.

Where to start

1. Pick one client account and list everyone who can reach its data today.
2. Try answering the March question for that account: who had access then, and when did it end for anyone who has left since?
3. Check your log retention against how far back clients ask, and extend it where you need to.
4. Replace shared admin logins with named accounts so every change carries a name.
5. Write down who approves access changes for each client account.

Onprem2Cloud IT Solutions Co. is a Microsoft CSP partner based in Muntinlupa City, Metro Manila. See the Seatvane page, our other in-house software on the software page, or contact us for a walkthrough. For what to expect from any provider, read what a managed Cloud PC service should let your administrator do.