Feature/privileged identity management

.gitignore

@@ -5,4 +5,6 @@ site/
 /quality-assurance/.vs
 /.vs
 
-node_modules/
+node_modules/
+
+/docs/copilot/

software-engineering-policies/CloudDevelopment/PrivilegedIdentityManagementJustificationGuidance.md

@@ -0,0 +1,30 @@
+# Writing a PIM activation reason
+
+This page helps engineers compose a reason for an engineering PIM activation under the proposed [PIM justification policy](PrivilegedIdentityManagementJustificationPolicy.md). The policy states the proposed requirements; this guidance is not a separate set of rules or a PIM user-interface guide.
+
+## Compose a reason
+
+A useful structure is `reference: privileged activity + system/service + business reason or expected outcome`. Use plain language rather than the literal plus signs. Describe the activity precisely enough to explain the access without including sensitive operational details.
+
+Choose the reference for the authorised work: an Azure DevOps work item for planned engineering work, an IT Portal request for a service request, or an incident or change record when responding to or changing a service. For live production work, include an IT Portal reference as required by the policy. If another record also helps explain the work, include its identifier without copying the record's sensitive contents. These are examples of references, not a claim that PIM connects to any of these systems.
+
+## Illustrative reasons
+
+These are fictional placeholders, not real identifiers or evidence of authorisation. `ADO-EXAMPLE` represents a work item, `IT-EXAMPLE` an IT Portal reference and `INC-EXAMPLE` an incident record. Replace them with the relevant authorised reference and accurate, non-sensitive description of your own work.
+
+| Situation | Too vague | More useful reason |
+| --- | --- | --- |
+| Planned non-production work | `Maintenance` | `ADO-EXAMPLE: adjust access configuration for test service to support planned deployment` |
+| Live production work | `Fix production` | `IT-EXAMPLE: inspect production service diagnostics for authorised incident response` |
+| Urgent incident response | `Urgent` | `IT-EXAMPLE / INC-EXAMPLE: restart production service to restore availability during incident response` |
+
+In an emergency, a concise, safe reason can identify the incident and the intended privileged activity. Update the incident record after recovery with the relevant details rather than putting sensitive details in the PIM reason. For live production work, the policy's IT Portal reference requirement still applies; use an authorised reference rather than inventing an identifier.
+
+## Check before activating
+
+- Can a reviewer tell what privileged activity is needed, which system or service is affected and why the work is authorised?
+- Is the role and activation duration proportionate to the work described?
+- Is the work reference appropriate, including an IT Portal reference for live production work?
+- Have you left out secrets, credentials, personal data and sensitive operational details?
+
+If the reason is still just a generic label, add the missing context without disclosing sensitive information. See the [policy](PrivilegedIdentityManagementJustificationPolicy.md) for the proposed obligations and review context.

software-engineering-policies/CloudDevelopment/PrivilegedIdentityManagementJustificationPolicy.md

@@ -0,0 +1,27 @@
+# PIM activation justification policy for engineers (draft)
+
+This engineering policy describes how engineers should justify an activation of an eligible Microsoft Entra Privileged Identity Management (PIM) role for UKHO engineering work.
+
+## Requirements for engineers
+
+When activating a PIM role for engineering work, engineers should:
+
+- Activate only the role needed for the authorised work, for the shortest duration needed to complete it.
+- Give a clear, traceable reason that identifies the privileged activity, the affected system or service, the business purpose or expected outcome, and the authorised work item. Include a reference that enables the work to be traced, such as an applicable Azure DevOps work item, IT Portal request, incident or change record.
+- Include an IT Portal reference for work on a live production system or service.
+- Keep secrets, credentials, personal data and sensitive operational details out of the reason. Use a reference to the authorised record rather than copying sensitive contents into PIM.
+
+A reason should be sufficiently specific to let a reviewer understand why the access is needed and relate it to the authorised work. At least 15 characters is a suggested writing aid, not an established technical minimum or a substitute for a meaningful explanation.
+
+## Review and challenge
+
+Activation reasons may be reviewed or challenged. A vague, missing or untraceable reason may need clarification and may lead to follow-up on whether the access was appropriate. This page does not establish a review schedule, name a reviewing team or assert that PIM automatically validates the content of a reason.
+
+## Terms and help
+
+- **PIM activation:** Temporary use of an eligible privileged role through Microsoft Entra Privileged Identity Management.
+- **Justification or reason:** The explanation supplied for that activation, connecting the access to authorised work without exposing sensitive details.
+- **Work reference:** An identifier for the authorised request, work item, incident or change record that allows the activity to be traced.
+- **Live production:** A system or service serving live operational use, as distinct from non-production work.
+
+For a suggested format, safe examples and a self-check, see the [PIM justification guidance](PrivilegedIdentityManagementJustificationGuidance.md). The guidance supports this proposed policy; it does not add requirements.

software-engineering-policies/CloudDevelopment/README.md

@@ -44,6 +44,10 @@ This policy applies to all software engineering teams and individuals within the
 
 [Cloud Pilot's License](PilotsLicense.md)
 
+[PIM activation justification policy (draft)](PrivilegedIdentityManagementJustificationPolicy.md)
+
+[PIM activation justification guidance (draft)](PrivilegedIdentityManagementJustificationGuidance.md)
+
 [Tagging](Tagging.md)
 
 ### Related Policies

software-engineering-policies/README.md

@@ -15,6 +15,7 @@ The policies (and associated guidance) that should be followed during software d
 | Open Source Contribution | [Policy](OpenSourceContribution/OpenSourceContributionPolicy.md) | |
 | Open Source Use | [Policy](OpenSourceUse/OpenSourceUsePolicy.md) | |
 | Pair Programming | [Policy](PairProgramming/PairProgrammingPolicy.md) | |
+| PIM activation justification (draft, engineers) | [Policy](CloudDevelopment/PrivilegedIdentityManagementJustificationPolicy.md) | [Guidance](CloudDevelopment/PrivilegedIdentityManagementJustificationGuidance.md) |
 | Secure Development | [Policy](SecureDevelopment/SecureDevelopmentPolicy.md) | |
 |   Managing Security Concerns | [Policy](../security/ManagingSecurityConcerns/ManagingSecurityConcerns.md) | |
 | Source Control | [Policy](SourceControl/SourceControlPolicy.md) | |