Merge pull request #860 from Jonathan-Scott14/patch-12

Update secrets-acl.html.md.erb

source/standards/secrets-acl.html.md.erb

@@ -5,14 +5,19 @@ review_in: 6 months
 ---
 # <%= current_page.data.title %>
 
-You should track the list of users who have access to secrets by logging the permissions, such as accounts and credentials, associated with a security resource in a single, centralised Access Control List (ACL). The list specifies who or what is allowed to access the resource and the operations which are allowed to be performed on the resource.
+You should track the list of users who have access to secrets by logging the permissions, such as accounts and credentials, associated with a security resource in a single, centralised Access Control List (ACL). 
+The ACL specifies who or what is allowed to access the resource containing secrets and the operations which are allowed to be performed on the resource. Also see Principle of Least Privilege for authentication and authorisation guidance.
 
-Some teams use a spreadsheet as their ACL to log the access to systems and secrets as a centralised source of truth for logging joiner, mover and leaver access.
-Teams should:
+ACL repositories used to log access to systems for storing and processing secrets should have designated colleagues within each directorate responsible for reviewing access granted on a defined periodic cadence (e.g. monthly, quarterly).
 
-- update the ACL to capture new joiner, mover and leaver access
-- create default access for the different roles and capture any deviations from the default
-- create a task to capture the progress of joiners, leavers and movers to make sure all the access has been granted, or removed and build this into the process
+Identified exceptions should be raised with the colleague responsible for risk management in the directorate for escalation.
+
+Teams ACL review should be documented to reflect:
+* who (colleague) completed the review
+* date review is undertaken
+* next review date
+* any changes to user status granted access, and the reason for change (if any). 
+* refer to new joiner, mover and leaver access process to reflect change in access status 
 
 ## Further guidance
 - [NCSC - 10 steps to cyber security](https://www.ncsc.gov.uk/collection/10-steps)