IAM and PAM governance
Somebody left, and their access did not.
Access is the first thing an auditor samples, the first thing an underwriter asks about, and the control set most organisations are quietly weakest on. This is advisory work: a structured review of how access is granted, changed, removed and evidenced across the systems you already run, and the design of the governance that keeps it that way. It is not a product module — CyberWave does not sell an identity or privileged access platform.
A review is scoped with you, not bought at a checkout. If you want the platform first: Start your 14-day free trial — no credit card required.
Where the findings end up. 0 access controls already sit in the example register — — and 2 controls in it still have no owner, which is the same failure this page is about. Example workspace: Northstar Manufacturing Ltd., fictional.
Where access governance breaks
Four sentences, and two of them were said in your organisation this year.
Access accumulates. Nothing in a normal working week surfaces it, every individual grant was reasonable at the time, and the total is a picture nobody has looked at.
- The leaver
“HR closed her file in March.”
The mailbox went away. The build server, the payment console, the shared repository and the vendor portal did not, because none of them were on anybody’s list.
Found by: an auditor, usually
- The joiner
“Give her the same access as him.”
Fast, effective, and it silently copies every excess permission the original person accumulated over four years. Two hires later nobody can say why anyone has what they have.
Found by: nobody
- The mover
“He has moved to finance — add the new access.”
Two events, one performed. After three moves one person can raise a purchase order, approve it, and change the approval rule.
Found by: a segregation-of-duties test
- The reviewer
“Approved — all 140 rows look fine.”
Eleven minutes, no exceptions raised, nothing revoked, and no record of what was examined — which is precisely the part an evidence request asks for.
Found by: fieldwork week
An access review that produces a spreadsheet and no revocations is a rehearsal.
The artefact that matters is not the export or the approval. It is the list of things somebody removed, on a date, with a name against it — and the record of the exception that was allowed to stay, with an expiry.
Joiner, mover, leaver
Three events, and most processes only handle two.
Joiner and leaver at least have owners — usually somebody in HR and somebody in IT, with a form between them. The mover has neither. A move is two events and most processes perform only the first.
| Criterion | Joiner | Mover | Leaver |
|---|---|---|---|
| What should happen | Access granted from a defined role, before the first day. | The new access is added and the old access is removed. | Every account closed, including the ones HR cannot see. |
| Who owns it today | Usually HR, with IT executing. | Nobody. The move is announced, not requested. | HR triggers it; IT closes what it knows about. |
| Where it breaks | “Give her the same as him” copies four years of accumulated permissions. | Only the addition is performed. Three moves later, one person can raise, approve and change the approval rule. | Vendor portals, cloud consoles, shared credentials, SaaS bought on a card, physical access. |
| What the engagement produces | A role definition you can review entitlements against — you cannot review access without a statement of what it was meant to be. | A removal step with a named confirmer, and handover exceptions that carry an expiry date rather than becoming permanent. | One checklist with an owner and a proof step, instead of four departmental habits. |
| The proof an auditor asks for | The approved role, and the record of what was granted against it. | The record that the old access was removed — not the record that it was requested. | The dated confirmation that each account was closed, per system. |
- What should happen
- The new access is added and the old access is removed.
- Who owns it today
- Nobody. The move is announced, not requested.
- Where it breaks
- Only the addition is performed. Three moves later, one person can raise, approve and change the approval rule.
- What the engagement produces
- A removal step with a named confirmer, and handover exceptions that carry an expiry date rather than becoming permanent.
- The proof an auditor asks for
- The record that the old access was removed — not the record that it was requested.
- What should happen
- Access granted from a defined role, before the first day.
- Who owns it today
- Usually HR, with IT executing.
- Where it breaks
- “Give her the same as him” copies four years of accumulated permissions.
- What the engagement produces
- A role definition you can review entitlements against — you cannot review access without a statement of what it was meant to be.
- The proof an auditor asks for
- The approved role, and the record of what was granted against it.
- What should happen
- Every account closed, including the ones HR cannot see.
- Who owns it today
- HR triggers it; IT closes what it knows about.
- Where it breaks
- Vendor portals, cloud consoles, shared credentials, SaaS bought on a card, physical access.
- What the engagement produces
- One checklist with an owner and a proof step, instead of four departmental habits.
- The proof an auditor asks for
- The dated confirmation that each account was closed, per system.
The engagement
Six stages, in an order that cannot be shuffled.
You cannot review entitlements you have not inventoried, cannot design a privileged access model before you know how many privileged accounts exist, and cannot make any of it recur until the decisions have owners.
- 01
Inventory
Where identities actually come from: the identity provider, systems keeping their own local accounts, SaaS nobody registered, contractors, and the shared credentials people admit to once you ask directly.
- 02
Entitlement review
Who has what, and on whose authority. This is where the leavers, the accumulated movers and the copied joiners surface — usually in the first pass, and in numbers that surprise the people who authorised them.
- 03
Privileged inventory
The privileged population, separately and explicitly: administrators, root and owner accounts, service accounts, break-glass accounts, and anyone able to change logging or access itself. Counted, named, attributed to a person.
- 04
Design
What good looks like here: which roles exist, what standing privilege remains and why, how elevation is requested and recorded, how break-glass credentials are held, and how service accounts get owners and rotation.
- 05
Recurring review
The review becomes a scheduled obligation with a defined reviewer, population and artefact — including what happens to an exception, the step most review processes never specify.
- 06
Into the register
Each decision lands in Sentinel as an access control with a named owner, the review as evidence with a date and an expiry, and every unresolved finding as a tracked action. The next review starts from the last one, not from a blank export.
This engagement reviews, designs and documents. It does not deploy your identity provider, configure single sign-on, install a credential vault or administer your accounts — those stay with your own team or whoever already runs them. What CyberWave contributes is the review, the design decisions, the written procedures, and the governance that makes them survive a change of staff.
Privileged access
Four questions a privileged access review has to answer.
A handful of accounts carry most of the consequence: nine people with permanent administrative rights because each needed it once, and a set of service accounts nobody will touch because nobody can say what breaks if they do. Small enough to examine one at a time.
- 01
How many people hold standing privilege, and why each one?
The question is not whether administrators exist. It is how many hold rights permanently because they needed them once, and whether each has a reason attached. The engagement works through which standing rights have to stay, which convert to a request-and-record process, and how the remainder are justified in writing.
- 02
Does the break-glass procedure survive being used?
Every environment needs a way in when the usual path fails, and most documented procedures fail one of three tests: the credential is reachable by too many people, using it produces no alert, and nobody has tested it since it was written. All three are checkable, and all three get checked.
- 03
Who owns the accounts that are not people?
Integration accounts, CI runners, API keys and scheduled jobs — passwords set years ago, no expiry, no rotation, and a name like svc-backup2. Each needs a human owner, a stated purpose, a rotation approach, and a decision about the privilege it actually needs rather than the privilege that made an install work.
- 04
What happens to third-party access when the engagement ends?
External access is where offboarding is weakest, because the trigger — a contract finishing — reaches nobody who administers the account. Contract end dates become expiry dates on the access itself, with an owner on your side.
The output is a privileged account inventory with a named human owner against every entry, a written position on the standing privilege that remains, a break-glass procedure that has been tested rather than drafted, and a review cadence for it.
Into the platform
Findings become controls, not a report.
This is the difference between an access review you paid for once and access governance you have. A report describes a moment. A control with an owner and evidence with an expiry describe an obligation that comes back around on a date.
The review becomes a row with a date on it.
Joiner, mover and leaver procedures, the privileged access model, the review cadence and the break-glass procedure each become a control with a named owner. The completed review is filed as evidence with a status and an expiry, linked to every control it supports — so once the expiry passes, the item is flagged in the evidence library instead of waiting for an auditor to ask.
- Access decisions become controls — with a named owner and a plain description of how it works here
- The review becomes dated evidence — with a status and an expiry, linked to the controls it supports
- Unresolved findings become actions — queued with assessment findings and risk treatments — 2 critical now and 0 overdue in the example workspace
- Answers are reused, not rewritten — access questions in an underwriting questionnaire or a customer security review are answered from the register, with the evidence attached
Why access, first
Every framework and every underwriter starts here.
This is not a CyberWave opinion about what matters most. It is where the questions demonstrably begin — which is why an access review pays for itself across four other conversations.
Answer it once and it is answered everywhere: the same access controls and the same dated evidence serve an ISO 27001 audit, a SOC 2 readiness profile, a customer security review and the multi-factor authentication question at the top of every renewal questionnaire.
Straight answers
What this service is not.
Everything below is something CyberWave does not do, stated before you ask rather than after you sign. In a market this crowded with overlapping words, being exact is the differentiator.
Not part of this engagement
- An identity provider, a single sign-on product, a provisioning engine, a credential vault or a session recording tool. CyberWave does not sell any of these, and Sentinel is not one.
- Administration of your accounts. We do not grant, change or revoke access in your systems — those actions stay with the people who own them.
- Real-time monitoring of privileged sessions, or alerting on account misuse. That is a detection capability; this is governance work.
- Managed security services, or a security operations centre watching access on your behalf.
- Emergency incident response. If an account has been misused, your incident response provider and your counsel lead that, not an advisory review.
- Penetration testing or technical exploitation of access paths. A review of entitlements and procedures is not a test of whether they can be bypassed.
- An audit opinion or a certification of your access controls. Those come from an independent auditor or an accredited certification body.
What remains is the part most organisations skip: knowing who has what, deciding who should, writing down how that is maintained, and holding the proof somewhere it will still be current in nine months. Your management retains decision authority over every access decision the review recommends.
Scope questions before a conversation: support@cyberwave.ca
Questions
What people ask before scoping a review.
Six questions that decide whether this is the right piece of work for you, answered plainly enough that you can tell before the call.
Is this an identity or privileged access product?
Our identity provider already has access review features. Why would we need this?
Do you need administrative access to our systems?
How often should access be reviewed?
Can this be a one-off, or does it have to be ongoing?
A one-off review is a reasonable place to start, and it produces something durable because the findings land in your workspace as controls, evidence and actions rather than in a report. What it cannot do is keep the review recurring, which is where a standing advisory cadence earns its place.
What does it cost?
The advisory work is scoped in a statement of work, because the effort depends on how many systems keep their own accounts and how much of the population is privileged — a number nobody can quote honestly before looking. The platform side is published: Essentials is $99/month and Full Platform is $249/month, both with 14-day trials and no card required.
Start with the leavers. It is always the leavers.
Pull the list of everyone who left in the last twelve months and check it against four systems that keep their own accounts. Whatever that turns up is the honest starting point for the rest of this work.
No credit card required
- Published pricing on every standard plan
- No credit card required for the trial
- No automatic charge when a trial ends
- Tenant-isolated architecture, data stored in Canada
- Clear data-processing terms
- No compliance guarantee — human judgement still required