# 7.4 Improvement Actions and Control Updates

# Goals

The Review section should not end with discussion. It should end with assigned improvement work.

After the company understands what happened, why it happened, and how well the response performed, it should turn those findings into practical changes.

The goal is to reduce the chance of the same incident happening again, reduce the damage if it does happen again, and improve how quickly the company can detect, respond, and recover.

Improvement actions should be specific, owned, prioritized, approved, and tracked to completion.

# Step 1: Convert Findings Into Actions

Start with the findings from the timeline, root cause analysis, control failure analysis, and response performance review.

Each finding should become one or more corrective actions.

Examples:

If MFA was missing, enable MFA on the affected systems and review all similar accounts.
If a backup failed silently, fix the backup alerting process and assign a backup owner.
If a phishing email was reported late, improve employee reporting instructions and add a phishing report button.
If a vendor account was abused, require named vendor accounts, MFA, access limits, and review dates.
If a website plugin was exploited, add the website to the patch and vulnerability management process.
If logs were missing, enable the required logs and set retention expectations.

A finding without an action is only a note.

# Step 2: Prioritize the Improvements

Not every improvement has the same urgency.

Prioritize actions based on risk, business impact, recurrence likelihood, effort, cost, and whether the issue affects critical systems or sensitive data.

High-priority actions should include items that address:

Active or recently exploited weaknesses
Missing MFA on critical systems
Admin access problems
Backup gaps
Known exposed services
Weak remote access
Unpatched internet-facing systems
Missing logs for critical systems
Public sharing of sensitive data
Vendor access weaknesses
Payment or fraud approval weaknesses
End-of-life systems

Lower-priority actions can still matter, but the company should fix the highest-risk repeat conditions first.

# Step 3: Assign an Owner and Due Date

Every improvement action needs a clear owner.

The owner may be IT, MSP, finance, HR, operations, legal, compliance, a system owner, a vendor manager, or a department lead.

Each action should also have a due date.

Avoid vague assignments such as “IT to review” or “management to consider.” Use clear wording such as:

“IT lead to enforce MFA on all finance and admin accounts by [date].”
“Backup owner to configure failed-job alerts to security mailbox and test alert delivery by [date].”
“Finance manager to update bank-detail change approval process by [date].”

If no one owns the action, it is unlikely to be completed.

# Step 4: Update the Actual Control

An improvement action should change something real.

This may include a technical setting, policy, procedure, checklist, vendor requirement, training material, monitoring rule, backup schedule, access review, or business approval process.

Examples of control updates include:

Enable MFA.
Remove local admin rights.
Disable legacy authentication.
Close public RDP or SSH.
Patch vulnerable software.
Update firewall rules.
Improve endpoint protection coverage.
Enable audit logs.
Add alerts for mailbox forwarding.
Add alerts for backup failures.
Restrict public file sharing.
Change payment approval steps.
Require vendor MFA.
Update the incident response contact list.
Add restore testing to the backup schedule.
Update employee reporting instructions.

The company should not mark an action complete until the control has actually changed.

# Step 5: Verify the Fix

After the improvement is implemented, verify that it works.

Examples:

Confirm MFA is enforced.
Confirm the old firewall exposure is closed from the outside.
Confirm backup failure alerts are received.
Confirm logs are visible and retained.
Confirm the phishing report button works.
Confirm the vendor account no longer has broad access.
Confirm the website scanner no longer reports the exploited vulnerability.
Confirm the updated finance approval process is being used.

Verification should be recorded.

Do not rely only on “we believe it was fixed.”

If the incident revealed that the playbook, checklist, contact list, or procedure was incomplete, update it.

Update relevant areas such as:

Assessment assumptions
Asset inventory
Data inventory
Access register
Dependency register
Backup procedure
Patch process
Hardening checklist
Detection alerts
Employee reporting instructions
Incident response procedure
Recovery priority list
Vendor access procedure
Business continuity workaround
Training materials

A good review improves the playbook itself.

# Step 7: Track Actions to Closure

Create an improvement action tracker.

Suggested fields:

Action ID
Incident ID
Finding
Improvement action
Control area
Priority
Owner
Approver
Due date
Status
Evidence required
Evidence location
Residual risk
Completion date
Review date

Do not close the Review section while important actions are unassigned.

If an action cannot be completed immediately, record the temporary control, risk owner, and review date.

# Step 8: Escalate Blocked or High-Risk Actions

Some improvements require budget, leadership approval, vendor support, downtime, or policy changes.

Escalate these clearly.

Examples include replacing unsupported systems, purchasing better backup protection, upgrading Microsoft 365 or Google Workspace licensing for audit logs, hiring external incident response support, changing MSP scope, or replacing a weak vendor.

Leadership should understand the risk of delaying important improvements.

If leadership accepts the risk, record that decision.

# Step 9: Confirm Completion With Leadership

Once priority improvements are completed or scheduled, provide leadership with a short update.

Include:

What was fixed
What remains open
Which risks were reduced
Which risks remain
What requires budget or approval
Which actions are overdue
Which policy or process changes were made
Which controls were verified

This closes the loop between incident review and business decision-making.

# Common Improvement Areas

Common improvement areas after incidents include:

MFA enforcement
Password management
Admin access restriction
Vendor access control
Patch management
Endpoint protection coverage
Backup monitoring
Backup immutability or offline copies
Restore testing
Email filtering
Mailbox rule alerts
Cloud and SaaS audit logging
Public sharing restrictions
Remote access hardening
Website patching
DNS and domain registrar protection
Security awareness training
Employee reporting path
Incident response contact list
Evidence handling rules
Communication approvals
Recovery priority list
Business continuity workarounds
Payment approval procedures
Data classification and access review

# Improvement Action Tracker Template

Use a simple tracker with these fields:

Action ID
Incident ID
Finding or gap
Root cause link
Control area
Improvement action
Priority
Owner
Approver
Due date
Status
Verification method
Evidence required
Evidence location
Residual risk
Temporary control
Completion date
Review date
Notes

# Expected Outputs from This Section

At the end of this section, the company should have:

Findings converted into improvement actions.
Actions prioritized by risk and business impact.
Owners assigned.
Due dates assigned.
Control updates defined.
Verification methods defined.
Playbook updates identified.
Improvement action tracker created.
Blocked or high-risk items escalated.
Leadership approval recorded where needed.
Completed actions verified.
Residual risks documented.

# Objective

Lessons learned only matter if they change controls.

A company should leave this section able to say:

“We know what must change, who owns it, when it is due, how it will be verified, and which risks remain until the work is complete.”

That is improvement actions and control updates.