Owners: who's accountable for each control, policy and vendor

Every control, test, policy, vendor, risk and cloud asset carries an owner — one named person accountable for it. That's the second half of the permission model: your role decides which modules you can open, and the owner decides who does the work on an individual record.

Assign owners early. It's the single highest-leverage bit of setup in the platform — automated checks look for them, and "who is responsible for this control?" is a question your auditor will definitely ask.

What an owner actually does

On policies and vendors the owner does the work, so name someone who will actually do it. On controls, tests, risks and assets the owner is the accountable name; any Owner or Administrator can still edit the record itself.

Two extra rules on risks, both there so your risk register survives scrutiny: a risk's owner and its reviewer must be two different people — whoever does the work shouldn't be the one signing it off — and the same person can't be swapped into both seats. On assets, cloud resources and repositories take an owner you choose; devices and tickets get theirs from the connected tool.

Who can be an owner

Owners and Administrators. That's the rule everywhere in the platform, not a quirk of one module — ownership means acting on the record, so it's limited to the roles that can act.

Members, Auditors and Portal Users aren't offered in owner pickers. If a colleague's name is missing from one, their role is the reason: change it in People Access and they'll appear. See roles and permissions for which role to give them.

Changing an owner

Owners move. People change teams and leave companies, and every owner in the platform can be reassigned as often as you need:

• A policy — open it and change the owner. The new owner picks up the draft exactly where it stood.
• A vendor — the Owner field on the vendor's overview is editable, by the vendor's owner or your organization's Owner.
• A control, test, risk or asset — set the owner on the record.

Nothing gets stranded. If a policy or vendor is sitting with someone who's left, reassign it and carry on — you never need to recreate a record to fix its owner.

Why owners aren't optional

Blank owners are a direct, avoidable reason your posture won't go green:

• An automated check confirms that every applicable control has an owner. One ownerless control fails it for the whole organization.
• Another confirms your policies have owners.
• Tests carry an owner too, and the Tests page shows how many are still unassigned.

When a framework is first set up, its policies all land with your organization's Owner. Spread them out to the people who'll actually maintain them, or one person becomes the bottleneck for every policy you have.

How to decide who owns what

• Own it if you can change the thing being tested. Whoever administers the cloud account owns the cloud controls. Whoever maintains the employee handbook owns the HR policies. An owner who can't fix the finding isn't an owner, they're a forwarding address.
• One name, not a team. "Engineering" isn't accountable; a person is. An auditor will say the same thing about a shared mailbox.
• Reassign when people move on. An owner who has left is worse than a blank one, because it still looks assigned.
• Don't let Administrator status stand in for ownership. Holding the role gets you to the page; being the owner is what makes you the person doing the work.