who had super admin on 12 march

Who had super admin on 12 March?

Who has it now is a screen you can open. Who held it on a specific date months ago, who granted it, and when it came off again is a different question, and most companies your size cannot answer it.

The reason is structural. Their tools were built to report a condition, and this is a question about a sequence.

state and history

Everything you can find out about your own environment falls into two categories.

State questions ask what is true now. Who is in this group. Which applications hold a grant against your mail. Which service accounts exist. What is shared with anyone who has the link. These are answerable at any time, by anybody with the console open, for as long as the company exists.

History questions ask what happened. When was this created and by whom. Did anyone open this file. Was that leaver’s access removed, and can you show it. What did that application read last quarter.

History questions are answered by logs, and logs have a horizon. Past that horizon the answer is neither “no” nor “yes”. It is gone, permanently, and no amount of effort or money recovers it after the fact.

Nobody at your company has ever looked at where that horizon is.

what these guides have been asking of you

Most of the checks in these guides are state questions. The guest accounts nobody counted. The applications holding scopes against your mail. The admins an acquisition brought with it. The service accounts nobody owns. Pull the list, look at it, act, and the answer is there whenever you get to it.

Two kinds of question are different, and they are the ones with teeth.

Has anyone left with administrative access, and can you show that it was removed? Can you show that it was removed is a question about your log. Your current access cannot answer it.

Who created this service account? The service accounts guide asks for the creator “where available”. For anything older than your horizon, it is not available, and that is permanent.

A third kind sits between the two: when did you last compare your account count to your headcount, when did you last confirm you could revoke a vendor. Those are questions about whether anybody wrote anything down, which is the cheaper failure and the more common one.

six months, and it is not about your plan

Here is the number.

Google keeps most Workspace audit logs for six months. Admin actions, sign-ins, Drive activity, OAuth token grants, groups, calendar, SAML: six months each. Email log search covers thirty days. Vault, which covers content rather than events, keeps what its retention rules say, indefinitely by default. Google lists these windows on its data retention page.

You would expect retention to vary by edition. As Google documents it, it does not: the window is the same on Business Starter as on Enterprise Plus.

Two other things do vary, and confusing all three is how the upgrade conversation gets started. The security investigation tool, which lets you search across logs and act on what you find, is limited to Enterprise and a few other editions. And a handful of individual event types are gated too: for example, the OAuth log records API call events, with the API name and method, only on Enterprise and equivalent editions.

So the real tier gap is narrower than the sales pitch. You have the same six months as everyone else. What you have less of is the ability to search it, and a few specific things it will not record for you at all.

That makes the question concrete. Everything older than six months is gone, for everybody, and the only intervention that changes it is somebody exporting a file on a schedule into somewhere that is not the system that produced it. The log export guide is that routine.

the two kinds of question

state

what is true now

• Who is in this group
• Which apps hold a grant
• Answerable any time, forever

history

what happened

• Who held a role on a date
• Was the leaver's access removed, and can you show it
• Gone after six months unless you exported it

the blind spots are more interesting than the horizon

Three things a log does not record well are worth more attention than how long it keeps what it does.

Permission state at a point in time. Logs record changes. They do not record conditions. To answer who held a role on a date, you replay every change backwards from today, and that only works if every relevant change is still inside the window. No screen anywhere shows you your access graph as it stood in March.

Actions taken on somebody’s behalf. Domain-wide delegation lets a service account act as any person in your organisation. When it does, the actor on the log line is the human being impersonated. Google records the delegation in a separate field, alongside the application’s identifier and name. So the information is there, and the default reading is wrong. If you have ever scanned an activity log and formed a view about what a colleague did, you were reading a field that software holding a delegation grant can fill in.

What your assistant retrieved. The Gemini log records feature use: that somebody summarised or generated something, and where in the interface. Prompts are not in there, and neither are the documents it pulled to answer. So the question the Copilot guide raises, what did the assistant surface for this person on this day, has no logged answer.

One piece of better news: when a third-party application reads a file through the Workspace APIs, Drive records it as its own event type, separate from a view or a download. So the application lists these guides ask you to produce are not purely theoretical, at least for Drive. Mail has nothing equivalent.

the page

The blast radius guide asks what your ten most-privileged identities could reach. This is the other page, and the two together are a quarterly pack.

A table. Four columns: the question, whether you can answer it today, how far back, and from which surface. Write the answers in plain words, without a score.

Ten rows, phrased the way an investor, a customer’s reviewer, an insurer or a regulator would put them:

Who had super admin on a named date six months ago? That sits exactly at the edge of the window, which makes it the honest test.

When was this account created, and by whom?

Which third-party applications read our files or mail last quarter, and what did they read?

Did anyone open this specific document, and when?

Was this leaver’s access removed, and can we show it?

What did the assistant retrieve for this person, on this day?

Which service account performed this action, and who was it acting as?

Was this file shared outside the company before we noticed, and by whom?

When did this token last authenticate, and from where?

If we learned today that an account was compromised in February, how much of February could we reconstruct?

Then, underneath, two sentences that are the point of the exercise:

These questions we cannot answer, and we have decided to live with that.

These we have decided to fix, by keeping the following, starting on this date.

The second list should be short. One or two rows, and the usual fix is somebody exporting a file once a quarter into a folder outside the system that produced it. That is the whole remediation budget, on purpose. There is a version of this argument that ends with a bigger plan, a log platform and somebody employed to run it, and at sixty people that version is wrong.

why the writing down is the intervention

The obvious objection: this produces a document, and the problem is still there.

Three answers.

“No” is a legitimate row. Most of your rows will say no, on any edition, and knowing that in advance is different from finding out during an incident. The company that never asked discovers the horizon at the worst moment, from a lawyer, in a sentence beginning “so you are telling me”.

It turns an unknown into a decision. An unanswerable question you have accepted in writing, dated, is a risk you carry on purpose. The same question, unexamined, is a surprise with your name on it. The logs look identical either way.

And it is something you can hand over. The blast radius page answers how bad it would be. This one answers how much of it you could prove. Almost every serious question about your security is one of those two, and having both written before the question arrives is the difference between a conversation and an incident.

the last line

An incident you cannot reconstruct did not happen, as far as anybody can prove.

That is a comfort for about as long as it takes somebody to ask you for the record. After that it is the whole problem, and by then the decision about which questions you could answer was made months ago, by nobody, through a default nobody read.

Write down which questions you cannot answer. Date it. Do it again next quarter, next to the blast radius page.