What your organization can see

If your account belongs to an organization, the people who administer it can see a short report about your security. Account → Security & compliance shows you that report — not a summary of it, not a reassuring paraphrase, but the identical row, from the identical place.

That is deliberate. A dashboard that reports on people who do not know it exists is a trust problem regardless of what is in it.

What this report shows#

It shows	It never shows
Your email address, your role, and when you joined	Your passwords, notes or files
When your account was last used, to the minute	Which credential is weak, its name, its address, or any field of it
Whether you have a second factor, and how many trusted devices and live sessions you hold	The contents of a personal vault — though the audit trail can name what you act on there
Whether you meet each policy your organization has switched on	Your master password, or anything about it beyond its age
How many of your credentials are weak, reused, aging or found in a breach, across every vault you hold — your personal vault included	What you do in the app, or when — that is the audit trail

The page shows them two ways, as your administrator's report does: credentials at risk, each counted once, and the findings behind them — weak, reused, aging, found in a breach. One credential can be both weak and reused, so the findings add up to more than the credentials. On a plan without breach monitoring the breach figure reads not monitored, never zero.

The counts are produced on your own device, during a vault analysis, and uploaded as plain numbers. Your organization's server has never held one of your credentials and could not produce one if an administrator demanded it. An administrator who needs the detail has to ask you.

The audit trail is a separate record#

Your organization also keeps an audit trail, and the people it gives audit access can read it. Depending on its audit settings, it records the actions you take in PulsVault while you are a member — signing in, changing your security settings, creating, opening, changing and sharing items and vaults, your personal vault included — each with its time and, where it was captured, the device and IP address it came from. An entry can show the name of the vault, item, note or folder it concerns: names are stored unencrypted so that you can search them.

It never holds a password, a note's text, a file's contents or any other encrypted field: the server never has them, so there is nothing for the trail to copy.

Why they see anything at all#

The organization pays for the seat, and somebody there is responsible for whether the organization is safe. "Four of our people are reusing a password that turned up in a breach" is a thing that person has to be able to know. "Which one is it" is not — and this is why the counts are the boundary rather than a setting someone could change.

What your organization needs from you#

Beneath the counts is the part that is yours to act on: everything your organization requires that you have not done yet, each with the page that satisfies it.

• A second factor, when your organization requires one. If you are inside an enrolment window the page shows how long is left — and when that window closes you will be refused at sign-in until you enrol, so this is the one worth reading first.
• A master password within your organization's age limit. Nobody can change it for you: it unwraps your vault key on your own device, so your organization can report that it is overdue and can do nothing else about it.
• A password that meets the current rules. If your organization tightened its password policy after you last set yours, your current password still works — the new rules apply the next time you change it. The report shows this as a fact, not a failure.
• Fewer trusted devices, or fewer live sessions, if you are over a limit your organization sets.

When none of these apply, the page says you meet every policy your organization enforces — the same answer your administrator's roster gives about you.

Under that, Policies your organization enforces lists every rule that is switched on — a second factor, the master-password rules, a maximum password age, verified email domains, a limit on live sessions or trusted devices — each marked met or not met. You cannot open the policy pages themselves, so this is where you can read what "every policy" means. It says whether a rule exists, not how your administrators configured it.

Never run a vault analysis? That is shown separately, because it is not a policy you are breaking. Until you run one your organization sees "never analysed" rather than a clean bill of health, and that is the honest reading: nothing has looked.

Each line links to the page that fixes it. You cannot open the policy pages themselves — those need administrative permissions — which is exactly why this page states the requirement and the remedy together.

This is not My security#

This page is the part your organization can see. Your own Security Center is the whole picture — which credentials are weak, which are reused, which turned up in a breach, and what to do about each — and none of that detail leaves your device.

Related#

• Two-factor authentication — enrolling a second factor
• Master password — changing it
• Devices and Active sessions
• Password health — where the counts come from