Who Owns Security When You Do Not Have a CISO?

Give one bounded action a real internal owner

Small teams rarely begin with a security department. Work is spread among an owner, an operations lead, a technically confident colleague, a contractor, and one or more service providers. That can be workable, but only if the team knows who can make the decision, who will perform the work, where completion evidence will be kept, and when the issue must move to someone with greater authority.

NIST SP 1300 asks small businesses to understand who within the business is responsible for developing and executing their cybersecurity strategy. NIST SP 1301 shows roles and responsibilities as supporting information that can accompany selected cybersecurity outcomes in an Organizational Profile.

Those sources support making responsibility visible. They do not prescribe the six functions, the one-accountable-owner rule, or the matrix in this guide. Those are PlainFort editorial choices for assigning one bounded action in a 1–50-person team. They are not a legal governance framework, a NIST requirement, or proof that a named person has the competence or authority to do the job.

Do not use this guide to decide directors’ duties, regulated governance, contractual accountability, or who is legally responsible for an incident. Seek qualified legal, governance, or security help when those questions apply.

Start after the action has been prioritized

Begin with one selected action from the security prioritization guide. SF-03 decides what should happen next by comparing consequence, exposure, dependency, reversibility, effort, uncertainty, and completion evidence. This guide begins only after that decision.

Do not rescore or reorder the work here. If the ownership exercise reveals a material missing fact, conflict, or unavailable authority that could change the priority, record the gap and return the action to SF-03 for reconsideration.

The security inventory may supply relevant context and a person who keeps an inventory row current. That row owner can be consulted or considered as a coordinator. They do not automatically become accountable for every security action involving the item.

Separate six functions

The six functions below are deliberately narrower than job titles. A person can hold more than one function, but the matrix should still show each function separately.

Accountable owner

The accountable owner is the one internal role that accepts the bounded decision, confirms the completion standard, follows the work through, and decides when to escalate within authority the business has actually granted.

As a PlainFort editorial rule, use exactly one accountable owner for each bounded action. This reduces the chance that several people each assume someone else will decide. It does not make that person a CISO, transfer a director’s duties, create legal accountability, or prove that the person has sufficient knowledge, time, independence, or authority.

Responsible executor

The responsible executor performs the work and produces the agreed completion evidence. The executor may be an employee, internal team, contractor, or service provider. Execution can be delegated; the business still needs an internal accountable owner.

Consulted party

The consulted party supplies input required before a decision or change. They may understand the affected business process, technical dependency, data use, or operational constraint. Consultation does not grant final accountability.

Informed party

The informed party receives an appropriate update about the decision, timing, result, or residual risk. They do not approve or execute the work merely because they are informed.

Backup

The backup is an internal role that can maintain continuity when the primary owner or coordinator is unavailable. Name what triggers handover and where the backup can find the non-secret evidence. A backup is not automatically a second accountable owner.

Escalation authority

The escalation authority can make or sponsor a decision when an observable threshold exceeds the accountable owner’s competence, capacity, independence, or granted authority. In a very small business this may be the business owner, but the matrix must describe authority that exists in practice rather than authority implied by a title.

If no internal accountable owner or escalation authority can be named, leave the gap visible. Do not assign it to a supplier by default.

Combine roles without hiding the consequences

A one-person business may need the same person to be accountable owner, executor, informed party, and escalation authority. Record each function anyway, then state that independent challenge and backup coverage are absent. The repeated name is not the problem; hiding the limitation is.

In a small team, the accountable owner may also execute low-complexity work when the person has the required capability, time, evidence access, and granted decision right. Consultation or information paths should still be named where another perspective or operational notice is needed.

Some combinations deserve separation or escalation. For example, a person should not approve evidence they cannot inspect, claim authority the business has not granted, or be presented as an independent check of their own conflicted decision. If practical separation is unavailable, record the conflict and the escalation needed rather than calling the assignment complete.

Use a lightweight responsibility matrix

Create one vertical block for each action. Keep evidence links in the team’s existing non-secret work system rather than embedding credentials, recovery codes, private contact details, sensitive configuration, or access instructions.

1. Selected action — the bounded output from SF-03. Not a new prioritization decision.
2. Decision/completion standard — what the accountable owner accepts and the observable condition for completion.
3. Accountable owner — exactly one internal role. Not an unverified title or public byline.
4. Responsible executor — the internal or external party that performs the work.
5. Consulted party — whose input is required before the decision or change.
6. Informed party — who needs an update and at what point.
7. Backup — who maintains continuity, what triggers handover, and where evidence can be found.
8. Escalation condition — the observable threshold that stops ordinary execution.
9. Escalation authority — the role with authority actually granted to decide or sponsor escalation.
10. Decision right — the specific decision the accountable owner can make without further approval.
11. Completion evidence and location — what shows the agreed work is done and where that non-secret record is kept.
12. Capacity/conflict check — any known time, competence, independence, authority, evidence-access, or conflict gap.
13. Review date or trigger — when the responsibility assignment will be revisited. This is not a priority score or a first-month calendar.

This is a responsibility record for one action, not an enterprise RACI chart, staffing plan, organization design, or compliance declaration. A completed block shows what was assigned. It does not prove that the action was effective or that the business is secure.

Check whether the assignment is real

Before work starts, ask:

1. Can the accountable owner explain the decision and completion standard?
2. Has the executor accepted the work, and do they have the required capability and separately governed access?
3. Can the accountable owner obtain and inspect the completion evidence?
4. Can the backup actually find the evidence and act when the handover trigger occurs?
5. Is the escalation threshold observable, and does the named authority have the power to act?
6. Is any conflict of interest visible and either mitigated or escalated?

Keep a failed check as an unresolved gap. Naming a person does not create time, competence, independence, access, or authority.

Delegate execution without outsourcing accountability

A contractor or provider may execute a configuration change, advise the team, or produce a test record. The responsibility block should still name one internal accountable owner who accepts the completion standard, can inspect the evidence, and owns escalation.

Do not copy vendor-access details into this matrix. Access paths, affected systems or data, privilege levels, external contacts, grant and expiry dates, recurring access reviews, exceptions, removal state, and closure evidence belong in the separate vendor access register. An executor assignment does not prove that the provider’s access is necessary, appropriate, or reviewed.

Worked example

Fictional example — do not copy as a completed responsibility assignment

Example Co. has already used SF-03 to select one invented action: confirm that recovery ownership for ExampleCRM continues when the usual operator is unavailable. This example uses roles rather than real people and contains no real provider, account, customer, credential, incident, or sensitive evidence location.

1. Selected action: Confirm continuity of the ExampleCRM recovery-ownership record.
2. Decision/completion standard: A current internal recovery role and backup are recorded, and both can locate the non-secret recovery evidence record.
3. Accountable owner: Operations lead — one internal role.
4. Responsible executor: Generic external service provider supplies a current service record; operations lead checks the internal record.
5. Consulted party: Client services lead confirms the business dependency.
6. Informed party: Business owner receives the result and any unresolved gap.
7. Backup: Business owner; handover occurs when the operations lead is unavailable for two working days; evidence location is Internal task record.
8. Escalation condition: The provider cannot supply usable evidence, or no internal role can exercise the required recovery decision.
9. Escalation authority: Business owner, within authority already granted by Example Co.
10. Decision right: Operations lead may accept or reject the internal record as complete; service or contractual changes require business-owner approval.
11. Completion evidence and location: Dated confirmation in Internal task record; no credentials or access instructions.
12. Capacity/conflict check: The operations lead has limited technical knowledge and depends on provider evidence, so the lack of independent technical review remains visible.
13. Review trigger: The usual operator, provider, recovery process, or business dependency changes.

The provider executes part of the work but does not become the internal accountable owner. Any access needed for execution must be handled in SF-05’s separate register. The example also remains incomplete in one meaningful sense: provider-supplied evidence has not received independent technical review. The matrix records that limitation rather than implying it has disappeared.

Hand the assignment to the first-month plan

Once the responsibility block is usable, it can become an input to the first 30 days guide. SF-04 does not assign week numbers, create the four-week roadmap, or decide due-date sequencing. A responsibility review date says when the assignment itself should be reconsidered; it is not the first-month calendar.

Limits and escalation

A responsibility matrix can expose ambiguity, but it cannot manufacture competence, capacity, independence, authority, or cooperation. It cannot verify a contractor’s internal security, determine legal accountability, satisfy a regulated governance requirement, or guarantee that an assigned action will be completed correctly.

Seek qualified professional or legal help when regulated governance may apply, a conflict cannot be managed internally, no internal accountable owner or genuine escalation authority can be assigned, the team cannot assess the evidence, or the decision exceeds the team’s expertise. Use an approved incident-response path for a suspected or active compromise rather than applying this routine ownership method during an incident.

The useful outcome is modest: one bounded action has an inspectable internal decision owner, an execution path, continuity coverage, evidence responsibility, and an honest escalation boundary. That is not certification that the business is secure.