Access Control and Audit Trails for Monitoring Teams

The shared account is the silent default mistake

Hardly any team decides to share a login. It happens in passing, because in that moment it is faster: a colleague only needs a quick look at response times, the agency should take over alerting for two weeks, the working student sets up checks for the new landing page. Every time, passing on the credentials is the path of least resistance, and every time the number of people who can act in the name of the same account grows without anything changing in the account itself. After a year, nobody knows exactly who holds the login. In no other piece of infrastructure would this state be accepted - in monitoring it goes unnoticed, because the tool produces nothing and is therefore rarely treated as a critical system.

Statistically this is no trifle. The human element is involved in 62 percent of all analysed breaches (Verizon DBIR 2026), and in the basic web application attack pattern, credentials were compromised in 52 percent of cases (Verizon DBIR 2026). The analysis draws on more than 22,000 confirmed breaches across 145 countries (Verizon DBIR 2026), which makes it broad enough to use as a bearing. Incidents that trace back to stolen credentials are also the most expensive single events in the insider category: 842,462 US dollars per incident on average (Ponemon Institute 2026). A shared monitoring account is exactly such a credential - one that by definition sits in several places at once and whose spread nobody can survey any more.

What access to monitoring actually means

A monitoring account looks harmless, because it sells nothing and manages no customer data. In practice it is a very dense description of your own infrastructure: the full list of every monitored address, endpoint, hostname and port, the response times and fault patterns of recent months, the alert recipient lists with phone numbers and addresses, often also credentials for monitored sign-in flows and checkout paths. Whoever opens this account sees at a glance which systems exist, when they weaken and whom to reach when something burns. At the same time it holds a switch that hardly any other tool offers: the ability to silence alerting. A paused check reports no outage - and in the overview it looks like a system that currently has no problems.

None of these actions is suspicious in itself. They belong to normal operations, and a team that is not allowed to perform them cannot work. The problem is not the capability but the anonymity: as long as everyone works under the same login, each of these changes is an act without an author. This gets particularly tricky with planned exceptions - as described in the article on maintenance windows and false alerts - because a forgotten maintenance window and a deliberately silenced check look identical on screen. Only attribution to a person turns a state into a decision you can talk about.

Cut roles by task, not by person

The usual reflex when granting rights is to follow the hierarchy: management gets a lot, the assistant gets little. That reliably produces the wrong rights in both directions - management can switch off checks it does not even know, and the assistant is not allowed to create what is actually their job. Cutting along the activity works better. The principle is old and cleanly described in the relevant frameworks: the module on identity and access management requires rights to follow actual need, their assignment to be documented and adjusted promptly when someone changes role (BSI IT-Grundschutz). The standard for information security management systems lists access control and the management of access rights as controls in their own right (ISO/IEC 27001:2022).

In practice the cut can be derived from four questions. Who needs to see numbers without changing anything? Who needs to create and adjust checks? Who decides who gets notified in an emergency? And who owns the contract and the invoices? Those four questions typically produce four to five roles, which is enough for the vast majority of teams. The order matters: describe the task first, then pick the role. Going the other way round and looking for a suitable role for a specific person tends to land on the next larger one - because at that moment it is hard to justify holding something back from a colleague. A permission matrix whose rows hold tasks rather than names takes the personal edge out of that discussion.

Multiple clients: client logins as a view boundary

As soon as more than one client sits in the same account, permission management becomes a contractual matter. A client's addresses, response times and fault histories are their operational data; making them visible in another client's interface is not carelessness but a breach of the confidentiality that was promised. The General Data Protection Regulation requires technical and organisational measures that ensure exactly this confidentiality (Art. 32 GDPR) and makes confidentiality a principle of processing (Art. 5 GDPR). For agencies, separation is therefore not a convenience feature but part of the service - the organisational frame is described in the article on website monitoring for agencies.

Read access for management and oversight

One group is regularly handled wrongly when rights are granted: management. Either they get no access at all - then they ask for numbers by email and someone compiles them by hand - or they get full access, because leadership should be allowed to see everything. Both are impractical, and both create risk in the wrong place. The NIS2 Directive explicitly obliges management bodies to approve risk management measures and oversee their implementation (NIS2 Directive Art. 20). That calls for insight, not intervention. A read-only login plus a recurring report delivers both: the numbers are available at any time, and nobody can accidentally switch off a check. How such reports are produced without extra work is shown in the article on automated client reports; for the running view, a status page or a scheduled report is often enough.

Offboarding: the login that quietly stays

The most dangerous access is rarely an attacker's. It belongs to a person who simply no longer belongs. Freelancers work along for three months, agencies change, staff leave. The logins remain, because their removal is written into no process and belongs to nobody. The insider risk numbers show where the weight lies: on average each organisation records 13.8 incidents from negligence, 6.3 incidents from malicious intent and 5.3 incidents from stolen credentials (Ponemon Institute 2026). The average time to containment recently fell to 67 days, yet only 13 percent of cases were closed within 30 days (Ponemon Institute 2026). The cost difference is substantial: if containment stretches beyond 90 days, the annual cost stands at 21.9 million US dollars against 14.2 million at under 30 days (Ponemon Institute 2026).

With a shared account, offboarding is an unpleasant operation: change a password, inform everyone, answer questions for three days. Because that means effort for everybody, it is frequently skipped in practice - and the departed person's access remains without anyone having taken a decision. With individual logins the same operation is a matter of seconds and afterwards appears in the log. What matters is that removal covers more than the sign-in: active sessions, stored keys and notification paths belong to it. How long the resulting log data may be retained is covered in the article on the retention policy for monitoring and analytics data.

1. Deactivate instead of delete: the user is blocked while their log entries stay attributable. A fully deleted account takes traceability with it.
2. End active sessions: a blocked sign-in helps little while a valid session is still open in a browser. Both steps belong together.
3. Review keys and automations: API keys and webhooks set up for the departing person outlive every password change and have to be withdrawn individually.
4. Reroute notification paths: alerts pointing to a personal address or phone number otherwise end up nowhere. The on-call chain has to be adjusted too.
5. Consider client logins: when an engagement ends, the logins on the client side and the associated status page addresses are withdrawn as well.
6. Log the removal: the blocking itself is an event worth documenting - typically the first thing an audit asks about.

Traceability: who changed the threshold?

A log is not an instrument of mistrust but a memory. It answers questions nobody else can answer any more, and it does so without debate. Normatively it has long been settled: the information security standard lists logging and the monitoring of activities as controls in their own right (ISO/IEC 27001:2022), the General Data Protection Regulation requires the ability to ensure confidentiality and integrity of processing and to review its effectiveness regularly (Art. 32 GDPR), and the NIS2 Directive counts access control and corresponding policies among the required risk management measures (NIS2 Directive Art. 21). That the effort pays off is shown by detection time: it takes a mean of 181 days for a breach to be noticed and 241 days in total until it is contained (IBM Cost of a Data Breach 2025). Anyone who wants to shorten that span needs traces that can be read.

Two follow-up questions decide the practical value of a log: how long does it stay available, and how fast do you reach the relevant line? In XICTRAQ the last 200 actions are visible directly in the dashboard, the log stays online for 180 days and is archived afterwards; a PDF export is available. For everyday work that means: a look into the log belongs in the review of every incident, in the way the article on incident management and escalation describes it. It also helps with silent faults - for instance when a paused check switches off exactly the guard that finds outdated pages after a release. How expensive such blind spots become is shown in the article on stale caches after a deploy.

Securing the sign-in: two-factor and passkeys

Roles and logs help little if the sign-in itself remains the weakest point. This is exactly where a lot has moved in a short time. According to the surveys of the responsible standards alliance, roughly five billion passkeys are in use worldwide, 90 percent of respondents know the method and 75 percent have enabled it on at least one account (FIDO Alliance 2026). Adoption in organisations is similarly advanced: 68 percent have deployed passkeys for employee sign-in or are deploying them right now (FIDO Alliance 2026). At the same time, 57 percent of organisations still sign in primarily with phishable methods (FIDO Alliance 2026) - the gap between availability and actual use is therefore the real finding. The success rate argues in the same direction: sign-ins with a passkey succeed in roughly 93 percent of attempts against 63 percent with classic methods (FIDO Passkey Index 2025).

The reason for the recommendation is technical. A passkey is a key pair whose private half does not leave the device and which is bound to the exact hostname of the sign-in page. A rebuilt page therefore cannot capture it, and in a server-side data leak there is no password to steal. The authoritative guideline for digital identities rates such methods as resistant to verifier impersonation and assigns them to the highest assurance level (NIST SP 800-63B); the NIS2 Directive lists multi-factor authentication explicitly among the required measures (NIS2 Directive Art. 21). To get started, a clear priority is enough: first the accounts with alert authority, meaning everyone who can pause checks, move thresholds or change recipient lists. Securing those accounts protects on-call itself; how it is set up organisationally is described in the article on the on-call rotation without burnout.

Organising monitoring access with XICTRAQ

Permission management feels like a task for later, because it makes nothing visibly better. Its value shows in exactly two moments: when someone leaves and when something goes wrong. In the first case it decides whether an access really ends. In the second, whether the question of why can be answered or dissolves into guesswork. Neither can be produced retroactively - a log begins on the day there are users who can be told apart. The effort for that is small and one-off; the effort of catching up later falls due exactly when nobody has time for it.

XICTRAQ is built so that a team does not have to share one account. Every member receives their own login with a role and website assignment, invitations run by email, and client logins can be restricted to the released websites. Security-relevant actions - sign-ins, permission changes, removed websites, generated keys - land in the audit log, which can be exported when needed. For sign-in, passkeys per the WebAuthn standard are available, complemented by classic methods as a fallback. And whoever wants to show externals only the state publishes a status page with its own address rather than handing out a login.

Check in the free trial how many people work under the same login today and how quickly that can be moved into separate roles. If you would rather walk through the setup together, book a personal demo and see the role model, website assignment and log on a real account.