Policies and other design controls
A design control is something you write once — a policy, a procedure, a standard, a template, a set of contract clauses. It's one document, so it's one task. Even if a policy only matters to one team, it's still one document, so still one task.
Access Control Policy is a design control. One task. It asks for the policy and the records that show it's real: approved, reviewed, shared with staff, acknowledged by the people it applies to.
Information security requirements in supplier agreements is also a design control. One task — the clauses and the standard agreement template.
Design controls are the one place where your environment doesn't change the number of tasks.
Process controls
A process control can be one task or many. It depends on whether the work is done once for the whole organisation, or repeated for each system, department or location.
Internal audit is run once, for the whole organisation. One task. Risk assessment is one exercise producing one risk register. One task.
Access provisioning, deprovisioning, access review and privileged access review are different. They happen per system. Ten systems in scope means ten tasks — unless you manage access to all of them through one platform, and then it's one. Vulnerability assessment and penetration testing work the same way: one task per system in scope.
So your systems list isn't just an inventory. It decides how many tasks get created and who gets them. Leave a system out and the access review for that system is never created. Nobody is asked for it. Nothing flags it.
Technology controls
Technology controls depend on what you've deployed and how it's managed.
MFA is one task per system if each system is configured on its own. If a single identity platform enforces MFA everywhere, it's one task on that platform.
Backup execution creates a task for each estate that's managed separately. An AWS account and a database estate are two tasks — different settings, different records, different people who can produce them.
Endpoint security is one task per tool. One OEM across all endpoints, one task. Two OEMs, because laptops and servers are handled differently, two tasks.
Where an integration is available, COMPASS pulls the evidence from the platform itself and nobody has to go and find it.
Is this just AI output?
No.
Every part of the automation — choosing the controls, creating the tasks, writing the testing procedures, checking the evidence — was built by GRC experts. People who work with these standards, run these audits, and know what an auditor will and won't accept. The rules COMPASS follows are their rules.
And at every stage that matters, a GRC expert reviews what COMPASS produced before it goes forward.
You get expert work at automation speed. Not a generic answer, and not an unchecked one.