How to Track Security Control Progress Across Teams

Security controls rarely belong to one team.

IT may configure access. Managers approve it. People Operations reports leavers. Engineering owns production systems. Procurement reviews suppliers. Leadership accepts material risk.

When progress is tracked separately, the control can appear complete even though one critical dependency is still missing.

Short answer: track security control progress across teams through one control register, one accountable owner per control, defined contributors and dependencies, shared status criteria, evidence-based completion, regular review cadences, and separate views for delivery teams and decision-makers.

The goal is not to make every team use the same task tool.

The goal is to maintain one reliable view of control outcomes, ownership, gaps, evidence, and decisions.

Why cross-team control tracking is difficult

Security work crosses normal organisational boundaries.

An access control may require:

• People Operations to report a joiner, role change, or leaver.
• A manager to approve access.
• IT to provision or remove accounts.
• An application owner to confirm permissions.
• Security to define privileged-access expectations.
• Internal audit to review a sample.

If each team tracks only its own task, nobody sees whether the full control outcome has been achieved.

Common symptoms include:

• Controls marked complete while evidence is missing.
• Several teams assuming someone else is the owner.
• Overdue dependencies hidden inside email or chat.
• Different status labels across spreadsheets.
• Policies approved before processes are operational.
• Audit preparation becoming a manual search.
• Leadership seeing a percentage without the high-risk gaps behind it.

Start with one source of truth

Use one control register as the authoritative view.

Teams can still manage detailed tasks in their existing tools. The register should hold the shared control-level information and link to those tasks.

A useful record includes:

See How to Build a Security Control Register for a Growing Business for a fuller register design.

Assign one accountable owner

Cross-team delivery does not require shared accountability.

Each control should have one accountable owner who:

• Understands the intended outcome.
• Coordinates contributors.
• Confirms the scope.
• Resolves or escalates dependencies.
• Checks that evidence exists.
• Reports gaps accurately.
• Reviews whether the control remains suitable.

Contributors own their assigned actions, but the accountable owner keeps the whole control from fragmenting.

For detailed ownership guidance, read ISO 27001 Control Ownership: How to Assign Accountability Without Confusion.

Map contributors by role, not by vague department

“IT,” “security,” or “the business” may be too broad to drive action.

Record the roles involved and what each role must deliver.

For example:

This is more useful than assigning every action to a committee.

Use status definitions that every team understands

Shared status labels prevent false progress.

A practical model is:

• Not assessed: applicability, scope, or current state is unclear.
• Planned: outcome and owner are agreed, but implementation has not started.
• In progress: design or deployment work is active.
• Blocked: a dependency or decision prevents progress.
• Deployed: the process or safeguard has been introduced.
• Operating: the control has completed its expected operating cycle.
• Evidenced: suitable proof exists for the relevant scope and period.
• Verified: an appropriate review has checked the control and evidence.
• Improvement required: the control operates but has an identified weakness.

Publish the definitions next to the register.

Do not allow each team to redefine “done.”

See What Makes a Security Control ‘Implemented’ in Practice? for the implementation test behind these stages.

Make evidence part of progress

Progress should not reach complete before the expected evidence exists.

For each control, define:

• Evidence type.
• Evidence owner or provider.
• Source system.
• Storage location.
• Period covered.
• Refresh frequency.
• Reviewer.
• Retention and protection needs.

For example, an access-review task is not complete only because managers attended a meeting. The evidence may need to show the user list reviewed, decisions made, removals completed, exceptions approved, and follow-up actions closed.

Evidence-based completion reduces arguments about status.

Track dependencies explicitly

Most cross-team delays are dependency problems.

Examples include:

• IT cannot remove access because People Operations did not report the change.
• Procurement cannot complete onboarding because the supplier did not answer security questions.
• Engineering cannot enable a control until leadership approves cost or downtime.
• A policy cannot be approved until legal reviews a contractual requirement.
• Internal audit cannot test a quarterly process before a cycle has operated.

For each dependency, record:

• The required input or decision.
• The team or role responsible.
• The date needed.
• The consequence of delay.
• The escalation path.

Do not hide a dependency inside a notes field that nobody reviews.

Separate control progress from task progress

A control may contain many tasks.

Completing most tasks does not always mean the control is nearly complete.

Imagine five access-control tasks:

• Draft policy.
• Define approval workflow.
• Enable MFA.
• Review privileged users.
• Remove identified excess access.

Four of five tasks may be complete, but the missing privileged-user review could still be the most important risk-reduction action.

Track both:

• Task progress: delivery work completed.
• Control status: whether the intended outcome is deployed, operating, evidenced, and verified.

This avoids misleading completion percentages.

Use risk-aware reporting

A simple count of green, amber, and red controls can hide material issues.

Report information such as:

• Overdue high-risk gaps.
• Controls blocked by leadership decisions.
• Applicable controls with no owner.
• Deployed controls awaiting an operating cycle.
• Controls with overdue evidence.
• Exceptions approaching expiry.
• Repeated control failures.
• Changes that affect scope or applicability.

If percentages are used, show the underlying risk and status counts as well.

Ten completed low-risk documentation tasks should not obscure one unresolved privileged-access gap.

Give different audiences different views

One source of truth can support several views.

Control-owner view

Show:

• Assigned controls.
• Next actions.
• Evidence due.
• Exceptions.
• Review dates.
• Blockers and dependencies.

Delivery-team view

Show:

• Tasks by team.
• Due dates.
• Required inputs.
• Technical or process dependencies.
• Links to implementation records.

Leadership view

Show:

• Material risks and overdue actions.
• Decisions or resources required.
• High-risk exceptions.
• Progress by workstream.
• Assurance findings.
• Significant changes or incidents.

Audit or customer-review view

Show only the relevant approved information:

• Control description.
• Policy reference.
• Owner role.
• Implementation status.
• Suitable evidence references.
• Approved limitations or remediation status.

Do not expose sensitive evidence broadly merely because the register contains a link.

Establish a review cadence

Different review levels serve different purposes.

A practical rhythm may include:

Frequent delivery review

Focus on active tasks, blockers, dependencies, and upcoming due dates.

Monthly control governance

Focus on high-risk gaps, resource decisions, exceptions, overdue evidence, and changes to scope or risk.

Periodic owner review

Control owners confirm status, evidence, operating results, and improvement actions at a frequency suited to the control.

Assurance review

Internal audit or another suitable reviewer independently checks selected controls and records findings.

The frequency should fit the organisation and the nature of each control. The important point is that reviews result in decisions and actions.

A cross-team example: joiners, movers, and leavers

Consider a user-access lifecycle control.

Intended outcome: users receive approved access for their current responsibilities, and access is changed or removed promptly when responsibilities or employment change.

Accountable owner: IT Manager.

Contributors:

• People Operations reports employment changes.
• Managers approve role-based access.
• IT provisions and removes accounts.
• Application owners verify specialist permissions.
• Security reviews privileged-access exceptions.

Evidence:

• Joiner, mover, and leaver tickets.
• Manager approvals.
• Account-creation and removal records.
• Periodic access-review results.
• Exception approvals.

Dependencies:

• Accurate and timely employee-change information.
• Current application-owner list.
• Defined approval rules.
• Integrations or manual steps for each in-scope system.

Progress test:

The control is not fully implemented only because a leaver form exists. It needs to operate across the intended systems, produce evidence, handle exceptions, and be reviewed.

Keep tooling proportional

A growing business can begin with a well-structured spreadsheet or work-management tool.

The tool should support:

• Stable control references.
• Ownership and permissions.
• Status definitions.
• Links to tasks and evidence.
• Due dates and reminders.
• Change history where practical.
• Useful filtered views.

Avoid building a complex platform before the team agrees on control outcomes, ownership, evidence, and status criteria.

The process model matters more than the software used to display it.

Common tracking mistakes

Assigning several owners

Multiple contributors are normal. Multiple accountable owners create ambiguity.

Using progress percentages without completion criteria

Percentages can look precise while hiding whether the control operates or has evidence.

Tracking policies instead of controls

Policy approval is one milestone. It does not show whether the related controls are deployed and operating.

Storing every detail in the central register

Keep the control-level view central and link to delivery tools. An overloaded register becomes difficult to maintain.

Letting evidence expire silently

Record review and refresh dates so recurring controls do not remain green after their evidence becomes stale.

Treating blocked as a failure to report

A visible blocker is useful. It gives leadership a chance to resolve a dependency before the control fails.

Where Aneo Framework Pro fits

Aneo Framework Pro helps small and growing businesses use questionnaire answers and business context to select relevant controls and generate tailored, editable security policy drafts and supporting readiness documents.

This can help establish a structured starting point for control and policy work. It is not a cross-team control-tracking platform and does not operate or verify controls for the organisation.

Teams remain responsible for assigning owners, managing actions, implementing controls, collecting evidence, reviewing progress, and making risk decisions. Framework Pro does not certify the business or replace legal advice, auditor judgement, or human review.

Quick FAQ

What is the best way to track security controls across teams?

Use one authoritative control register with one accountable owner per control, named contributors, explicit dependencies, shared status definitions, evidence requirements, and regular governance reviews.

Should every team use the same project-management tool?

Not necessarily. Teams can use their normal delivery tools if the central control register retains a reliable control-level status and links to the relevant tasks and evidence.

Who should update control status?

Contributors can update their tasks, but the accountable control owner should confirm the overall control status and evidence against shared completion criteria.

How should blocked controls be reported?

Record the blocker, responsible role, required decision or input, impact, target date, and escalation path. Keep high-risk blockers visible to the appropriate decision-makers.

Is percentage complete a useful security metric?

It can support delivery reporting, but it should not stand alone. Pair it with risk, control stage, overdue evidence, exceptions, blockers, and independent verification.

When should a control be marked complete?

Use a defined status such as operating, evidenced, or verified. Recurring controls should remain subject to future review rather than being treated as permanently complete.

Final thought

Cross-team security work becomes manageable when accountability and dependencies are visible.

Use one control-level source of truth. Give every control one accountable owner. Let contributors manage detailed tasks in familiar tools. Define status through evidence and operating outcomes. Escalate blockers early. Give each audience the view it needs.

That creates progress reporting people can act on and trust.