From a9fc30510ff756869ebf98371f60a60c81ddf859 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E2=80=9CJerome?= <“Jerome.wanliss@hackney.gov.uk”> Date: Wed, 2 Jul 2025 15:29:48 +0100 Subject: [PATCH 1/4] Chore: creation of technical standard --- ...uction Environment Tools & PII Handling.md | 66 +++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 docs/technical-standards/How-to guides/Production Environment Tools & PII Handling.md diff --git a/docs/technical-standards/How-to guides/Production Environment Tools & PII Handling.md b/docs/technical-standards/How-to guides/Production Environment Tools & PII Handling.md new file mode 100644 index 0000000..71468d8 --- /dev/null +++ b/docs/technical-standards/How-to guides/Production Environment Tools & PII Handling.md @@ -0,0 +1,66 @@ +--- +title: Production Environment Tools & PII Handling +--- + +# Production Environment Tools & PII Handling +# 1. Purpose + +This standard defines minimum security and privacy expectations for developers when using third-party tools (like Postman) to access Hackney’s production environments or interact with Personally Identifiable Information (PII). + +The goal is to reduce the risk of exposing sensitive resident data through insecure or inappropriate tooling. + +# 2. Scope + +Applies to all Hackney Council staff, contractors, and third parties who access production environments or handle production data containing PII. + +Covers all development, testing, debugging, or API interaction tools used in production contexts. + +# 3. Requirements + +## Tool Usage in Production Environments + +### Prohibited Use of Unvetted Tools + +Developers must not use third-party tools to access production environments or handle production PII unless they have a clear and documented understanding of how the tool manages, stores, and transmits data, and are satisfied that its use aligns with Hackney’s security and data protection standards. + +Where a new tool is approved for use, supporting evidence of this assessment must be recorded in the [Hackney Service Catalogue](https://docs.google.com/spreadsheets/d/1QoinQ9Yvlr4gvUoROYAA8vDWOWyXw7-vokZmPEH296A/edit?gid=1633075159#gid=1633075159). + +### Approval Process for New Tools + +Before using any new tool for production data, developers must: + +- Obtain approval from the Head of Engineering. +- Add approved tools to the [Hackney Service Catalogue](https://docs.google.com/spreadsheets/d/1QoinQ9Yvlr4gvUoROYAA8vDWOWyXw7-vokZmPEH296A/edit?gid=1633075159#gid=1633075159), so that its use is documented and visible to relevant teams. + +### Assessment Criteria for Tool Approval + +When assessing a tool for use in production environments with PII, the following minimum requirements apply: + +1. The tool must not store request or response data in external or cloud environments unless this has been formally reviewed and approved. +2. If the tool stores data locally, it must provide controls to securely manage and delete this data. +3. The tool must encrypt data in transit (e.g. using HTTPS/TLS) when communicating with production systems. +4. If the tool stores data at rest (locally or remotely), it must use encryption for that stored data. +5. The tool must not retain sensitive data longer than necessary for the task being performed. Where the tool is cloud-based or connects to external services, it must provide a clear and accessible privacy policy explaining data retention periods, storage locations and third party access. +6. The tool must provide mechanisms to restrict access to sensitive data, such as user authentication and role-based access control, especially for tools used by multiple developers in differing teams. +7. Where the tool collects telemetry, usage data, or analytics, this functionality must be disabled. + - If this is not possible, the tool must be reviewed and approved before use with production systems or data. +8. Where audit logging exists within a tool, logging of sensitive data (such as request and response bodies) must be disabled. + - If this is not possible, the tool must be reviewed and approved before use with production systems or data. + +# Communication and Developer Awareness + +## Responsibility for Communication + +The Head of Engineering must ensure this standard is communicated across all development teams, including internal staff, contractors, and third-party developers. + +# Appendix A - Example: Postman + +## Risk Summary + +Postman automatically stores API request and response data locally and in the cloud (depending on settings), including headers, parameters, and body content that may contain PII. + +| Tool | Risk Description | Assessment | +|---------|------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------| +| Postman | Persistent storage of API requests, headers, and bodies by default. Risk of exposing PII locally or to Postman’s cloud infrastructure. | Not approved for use with production PII | + +This result would then be recorded in the [Risk Log](https://docs.google.com/spreadsheets/d/1UGbxoImySTqDLUWc1Ifbp61iN3uLjfRBaK4lvyZ55Bo/edit?gid=0#gid=0) From 3c5bf4ba6bfb50eb24db8d3586a8ff24a9afbf14 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E2=80=9CJerome?= <“Jerome.wanliss@hackney.gov.uk”> Date: Wed, 2 Jul 2025 15:58:28 +0100 Subject: [PATCH 2/4] updated text --- .../Production Environment Tools & PII Handling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/technical-standards/How-to guides/Production Environment Tools & PII Handling.md b/docs/technical-standards/How-to guides/Production Environment Tools & PII Handling.md index 71468d8..6ccb8c3 100644 --- a/docs/technical-standards/How-to guides/Production Environment Tools & PII Handling.md +++ b/docs/technical-standards/How-to guides/Production Environment Tools & PII Handling.md @@ -23,7 +23,7 @@ Covers all development, testing, debugging, or API interaction tools used in pro Developers must not use third-party tools to access production environments or handle production PII unless they have a clear and documented understanding of how the tool manages, stores, and transmits data, and are satisfied that its use aligns with Hackney’s security and data protection standards. -Where a new tool is approved for use, supporting evidence of this assessment must be recorded in the [Hackney Service Catalogue](https://docs.google.com/spreadsheets/d/1QoinQ9Yvlr4gvUoROYAA8vDWOWyXw7-vokZmPEH296A/edit?gid=1633075159#gid=1633075159). +Where a new tool is approved for use, supporting evidence of this assessment must be recorded in the [Hackney Service Catalogue](https://docs.google.com/spreadsheets/d/1QoinQ9Yvlr4gvUoROYAA8vDWOWyXw7-vokZmPEH296A/edit?gid=1633075159#gid=1633075159) in columns Q to U. ### Approval Process for New Tools From 94f4c2a34a352ed2924da263f45514644bfc54f1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E2=80=9CJerome?= <“Jerome.wanliss@hackney.gov.uk”> Date: Wed, 2 Jul 2025 17:25:19 +0100 Subject: [PATCH 3/4] Folder structure and naming changes --- .../Production Environment Tools & PII Handling.md | 1 + .../Reference/Development-standards/_category_.json | 5 +++++ .../Reference/hosting-standards/Readme.md | 3 --- 3 files changed, 6 insertions(+), 3 deletions(-) rename docs/technical-standards/{How-to guides => Reference/Development-standards}/Production Environment Tools & PII Handling.md (99%) create mode 100644 docs/technical-standards/Reference/Development-standards/_category_.json diff --git a/docs/technical-standards/How-to guides/Production Environment Tools & PII Handling.md b/docs/technical-standards/Reference/Development-standards/Production Environment Tools & PII Handling.md similarity index 99% rename from docs/technical-standards/How-to guides/Production Environment Tools & PII Handling.md rename to docs/technical-standards/Reference/Development-standards/Production Environment Tools & PII Handling.md index 6ccb8c3..9b01530 100644 --- a/docs/technical-standards/How-to guides/Production Environment Tools & PII Handling.md +++ b/docs/technical-standards/Reference/Development-standards/Production Environment Tools & PII Handling.md @@ -1,5 +1,6 @@ --- title: Production Environment Tools & PII Handling +sidebar_position: 1 --- # Production Environment Tools & PII Handling diff --git a/docs/technical-standards/Reference/Development-standards/_category_.json b/docs/technical-standards/Reference/Development-standards/_category_.json new file mode 100644 index 0000000..04acc01 --- /dev/null +++ b/docs/technical-standards/Reference/Development-standards/_category_.json @@ -0,0 +1,5 @@ +{ + "collapsible": false, + "collapsed": false, + "label": "Development Standards" +} diff --git a/docs/technical-standards/Reference/hosting-standards/Readme.md b/docs/technical-standards/Reference/hosting-standards/Readme.md index ab91917..52c69f0 100644 --- a/docs/technical-standards/Reference/hosting-standards/Readme.md +++ b/docs/technical-standards/Reference/hosting-standards/Readme.md @@ -1,6 +1,3 @@ ---- -sidebar_position: 1 ---- # Hosting standards Hosting standards apply to everything we host at Hackney, whether it's built in-house, developed externally, or an off-the-shelf product. If we're hosting it in one of our cloud platforms, e.g. AWS, these standards apply From 9b1ea60bc9387b668dd9ac180cc2873a90b99292 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E2=80=9CJerome?= <“Jerome.wanliss@hackney.gov.uk”> Date: Wed, 16 Jul 2025 15:52:23 +0100 Subject: [PATCH 4/4] meaning expansion and formatting --- ...uction Environment Tools & PII Handling.md | 34 ++++++++++--------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/docs/technical-standards/Reference/Development-standards/Production Environment Tools & PII Handling.md b/docs/technical-standards/Reference/Development-standards/Production Environment Tools & PII Handling.md index 9b01530..4313205 100644 --- a/docs/technical-standards/Reference/Development-standards/Production Environment Tools & PII Handling.md +++ b/docs/technical-standards/Reference/Development-standards/Production Environment Tools & PII Handling.md @@ -22,37 +22,39 @@ Covers all development, testing, debugging, or API interaction tools used in pro ### Prohibited Use of Unvetted Tools -Developers must not use third-party tools to access production environments or handle production PII unless they have a clear and documented understanding of how the tool manages, stores, and transmits data, and are satisfied that its use aligns with Hackney’s security and data protection standards. +Developers **must not** use third-party tools to access production environments or handle production PII unless they have a clear and documented understanding of how the tool manages, stores, and transmits data, and are satisfied that its use aligns with Hackney’s security and data protection standards. -Where a new tool is approved for use, supporting evidence of this assessment must be recorded in the [Hackney Service Catalogue](https://docs.google.com/spreadsheets/d/1QoinQ9Yvlr4gvUoROYAA8vDWOWyXw7-vokZmPEH296A/edit?gid=1633075159#gid=1633075159) in columns Q to U. +Where a new tool is approved for use, supporting evidence of this assessment **must** be recorded in the [Hackney Service Catalogue](https://docs.google.com/spreadsheets/d/1QoinQ9Yvlr4gvUoROYAA8vDWOWyXw7-vokZmPEH296A/edit?gid=1633075159#gid=1633075159) in columns Q to U. ### Approval Process for New Tools -Before using any new tool for production data, developers must: +Before using any new tool in a production environment — particularly where it may interact with PII — developers **must** complete the [Developer Tool Assessment Checklist](https://forms.gle/j9fWxAHvHdMrZ8wq8). -- Obtain approval from the Head of Engineering. -- Add approved tools to the [Hackney Service Catalogue](https://docs.google.com/spreadsheets/d/1QoinQ9Yvlr4gvUoROYAA8vDWOWyXw7-vokZmPEH296A/edit?gid=1633075159#gid=1633075159), so that its use is documented and visible to relevant teams. +Once the checklist is submitted: + +- The developer **must** notify the Head of Engineering, who will review the responses for overall suitability. +- If the tool is approved, the developer **must** add it to the [Hackney Service Catalogue](https://docs.google.com/spreadsheets/d/1QoinQ9Yvlr4gvUoROYAA8vDWOWyXw7-vokZmPEH296A/edit?gid=1633075159#gid=1633075159) along with all supporting evidence, such as privacy policies, configuration screenshots, or network behavior logs. This is so that its use is documented and visible to relevant teams. ### Assessment Criteria for Tool Approval When assessing a tool for use in production environments with PII, the following minimum requirements apply: -1. The tool must not store request or response data in external or cloud environments unless this has been formally reviewed and approved. -2. If the tool stores data locally, it must provide controls to securely manage and delete this data. -3. The tool must encrypt data in transit (e.g. using HTTPS/TLS) when communicating with production systems. -4. If the tool stores data at rest (locally or remotely), it must use encryption for that stored data. -5. The tool must not retain sensitive data longer than necessary for the task being performed. Where the tool is cloud-based or connects to external services, it must provide a clear and accessible privacy policy explaining data retention periods, storage locations and third party access. -6. The tool must provide mechanisms to restrict access to sensitive data, such as user authentication and role-based access control, especially for tools used by multiple developers in differing teams. -7. Where the tool collects telemetry, usage data, or analytics, this functionality must be disabled. - - If this is not possible, the tool must be reviewed and approved before use with production systems or data. -8. Where audit logging exists within a tool, logging of sensitive data (such as request and response bodies) must be disabled. - - If this is not possible, the tool must be reviewed and approved before use with production systems or data. +1. The tool **must not** store request or response data in external or cloud environments unless this has been formally reviewed and approved. +2. If the tool stores data locally, it **must** provide controls to securely manage and delete this data. +3. The tool **must** encrypt data in transit (e.g. using HTTPS/TLS) when communicating with production systems. +4. If the tool stores data at rest (locally or remotely), it **must** use encryption for that stored data. +5. The tool **must not** retain sensitive data longer than necessary for the task being performed. Where the tool is cloud-based or connects to external services, it **must** provide a clear and accessible privacy policy explaining data retention periods, storage locations and third party access. +6. The tool **must** provide mechanisms to restrict access to sensitive data, such as user authentication and role-based access control, especially for tools used by multiple developers in differing teams. +7. Where the tool collects telemetry, usage data, or analytics, this functionality **must** be disabled. + - If this is not possible, the tool **must** be reviewed and approved before use with production systems or data. +8. Where audit logging exists within a tool, logging of sensitive data (such as request and response bodies) **must** be disabled. + - If this is not possible, the tool **must** be reviewed and approved before use with production systems or data. # Communication and Developer Awareness ## Responsibility for Communication -The Head of Engineering must ensure this standard is communicated across all development teams, including internal staff, contractors, and third-party developers. +The Head of Engineering **must** ensure this standard is communicated across all development teams, including internal staff, contractors, and third-party developers. # Appendix A - Example: Postman