Control Owner
A control owner is the specific, named person accountable for a control operating: the one who runs the quarterly access review, keeps the vendor register current, ensures backups restore. Not a team, not a role-to-be-hired — a name, with the authority and hours to do the job.
Why frameworks quietly require it
ISO 27001 expects responsibilities assigned; SOC 2 auditors ask “who performs this control?” and sample that person’s work; regulators escalate the question to governance (“who owns technology risk?”). But the deeper reason is operational: every control without an owner is a control that decays — the entire catalog of program failure patterns reduces to ownership gaps wearing different costumes.
What good ownership assignment looks like
Every control in your set maps to a person (the platform should enforce the field); owners have the access and authority to actually perform the control; ownership transfers explicitly when people leave (orphaned controls are an offboarding checklist item); and the load is honest — one engineer owning forty controls at 0% allocated time is a stalled program with extra steps.
The startup reality
At 20 people, one person owns most controls part-time, and that’s fine if the time is real. When it isn’t, the choices are the honest ones: reassign, automate the mechanical share, or rent the ownership until a hire makes sense. The unavailable option is the default one — nobody, quietly.
Access Review — An access review is the periodic check that everyone's system access matches their role — the most-sampled SOC 2 control and the most common exception.
Evidence Collection — Evidence collection is gathering the proof that controls operate — the audit's real workload, and the part automation genuinely transformed.
Risk Register — A risk register is the living record of identified risks, their scores, owners, and treatments — sampled in every SOC 2 and ISO 27001 audit.