Merge pull request #916 from Jonathan-Scott14/patch-20

Update principle-least-access.html.md.erb

source/standards/principle-least-access.html.md.erb

@@ -1,14 +1,14 @@
 ---
 title: Principle of Least Privilege
-last_reviewed_on: 2023-11-20
+last_reviewed_on: 2024-06-27
 review_in: 6 months
 ---
 
 # <%= current_page.data.title %>
 
 The [principle of least privilege][polp] involves setting up user accounts so they can only access and use the information they need for specific tasks. This can also apply to processes and individuals who might have to switch between normal access and the increased access of a superuser account as part of their work.
 
-All access provisioned for use within GDS must be provided on a least privilege basis
+All access provisioned for use within GDS must be provided on a least privilege basis.
 
 Examples of privileged or higher security access are:
 
@@ -38,6 +38,8 @@ Your team should:
 - in cases where JIT access is not implemented for users with privileged access that have critical business impact, implement a documeneted periodic review (cadence to be defined) of the need to continually have these privileged access granted to confirmed users
 - have a Joiners, Movers and Leavers process, where line managers (or equivalent) arrange for privileged access to be removed (SLA to be defined) where it is not required. See this [NCSC guide on identity management](https://www.ncsc.gov.uk/guidance/introduction-identity-and-access-management) for more information.
 
+It's important to recognise opportunities for privilege creep / accumulation and to design in suitable processes for preventing it.
+
 ## Examples
 
 For human-readable secrets, such as a username and password, you should set up a separate secret or [password manager](https://www.ncsc.gov.uk/collection/passwords/password-manager-buyers-guide).