ITPOL15 Software Development Policy

ITPOL15

Software Development Policy

Page 1 of 21

Version:

V2

Ratified by:

Finance & Investment committee

Date ratified:

02/04/2025

Job Title of author:

Assistant Director of IT, Development Technology Program Group

Reviewed by Committee or Expert Group Equality Impact Assessed by: Related procedural documents

Review date:

Systems

&

Assistant Director of IT, Systems & Development ITPOL05 Software Management Policy QSPOL01 Incident Reporting and Management Policy IGPOL53 Information Security Policy 02/04/2028

It is the responsibility of users to ensure that you are using the most up to date document template – ie obtained via the intranet.

In developing/reviewing this policy Provide Community has had regard to the principles of the NHS Constitution.

Page 2 of 21

Version Control Sheet Version V1

Date April 2024

27/02/2025 V2

Author Status Assistant New Director – IT, Systems & Development Director of Technology

Page 3 of 21

Comment

Align with ISO27001 2023

Contents 1.

Introduction .................................................................................................... 5

2.

Scope ............................................................................................................ 5

3.

Definitions ...................................................................................................... 5

4.

Security in the Development lifecycle............................................................. 6

5.

Design Approach for Code ............................................................................. 9

6.

Secure and Compliant Development Environment ....................................... 10

7.

Ongoing Security Compliance..................................................................... 11

8.

Consultation and Communication ................................................................ 12

9.

Duties .......................................................................................................... 13

10. Internal Security Assessment....................................................................... 14 Appendix 1: Security Assessment Checklist ........................................................ 16 EQUALITY IMPACT ASSESSMENT TEMPLATE: Stage 1: ‘Screening’ .............. 18 EQUALITY IMPACT ASSESSMENT TEMPLATE: Stage 2: ................................. 20

Page 4 of 21

1. Introduction This policy ensures that Provide CIC and its group companies adopt a secure approach to software development. By integrating security throughout the development lifecycle and implementing a robust approval process, we aim to mitigate associated risks. The policy draws upon the National Cyber Security Centre (NCSC) guidance, Data Security & Protection Toolkit (DSPT) requirements, and industrystandard best practices, with an emphasis on aligning with ISO 27001 standards where applicable.

2. Scope This policy applies to all types of software development within Provide CIC and its Group Companies, including in-house, outsourced, and open-source contributions. It is also mandatory for any entity commissioned to undertake development work on behalf of Provide.

3. Definitions Software Development Lifecycle (SDLC): The process encompassing all phases of software creation, from initial planning and analysis through design, development, testing, deployment, maintenance, and eventual retirement.

Information Security: Measures and processes designed to protect digital and nondigital information from unauthorised access, disclosure, disruption, modification, or destruction.

Data Security & Protection Toolkit (DSPT): A framework used within the UK's health and social care sectors to ensure that organisations process personal and sensitive data securely.

National Cyber Security Centre (NCSC): The UK government organization responsible for providing guidance and support on cybersecurity and cyber resilience.

Information Standards Notices (ISN): Formal notifications issued to the NHS concerning the introduction, amendment, or withdrawal of information standards.

IT Security Skills: The knowledge and abilities related to the implementation and management of security measures to protect computer systems, networks, and data.

Security Assessment Checklist: A tool or document used to guide the security evaluation of software developments, ensuring they meet specified security criteria before deployment.

Data Protection Impact Assessment (DPIA): A process to help identify and minimise the data protection risks of a project or plan involving the processing of personal data.

Page 5 of 21

Code Escrow: The deposit of the source code of software with a third-party escrow agent, allowing the licensee to access the source code if the licensor fails to meet certain conditions, such as going out of business.

CareCERT Notifications: Alerts and guidance issued by the NHS Digital's CareCERT (Care Computing Emergency Response Team) providing advice on protecting IT systems and data within health and social care sectors against cyber threats and vulnerabilities.

Intellectual Property (IP) Rights: Legal rights that grant creators and owners exclusive rights to use and exploit their creations and inventions.

Vulnerability Assessment: The process of identifying, quantifying, and prioritizing (or ranking) the vulnerabilities in a system.

Change Control Process: A systematic approach to managing all changes made to a product or system, ensuring that no unnecessary changes are made, that all changes are documented, that services are not unnecessarily disrupted, and that resources are used efficiently.

4. Security in the Development lifecycle Security is paramount and must be integrated at every stage of the development lifecycle, beginning even before the initiation of development work. To ensure a secure foundation: •

Documentation of Security Requirements: All parties must clearly understand and document the security requirements from the outset. These requirements should balance the need for functionality with essential security measures.

•

Adherence to Standards: It's crucial to identify and integrate applicable standards into the development process. For Health & Social Care products, Information Standards Notices must be included as part of the design considerations.

•

Skillset of Development Team: The responsible manager or project lead must select staff with appropriate IT security skills, ensuring a blend of practical experience and recognised certifications among the team members.

•

Encouragement of Proactive Security Discussions: The development team is encouraged to actively raise security concerns, ask questions, and challenge assumptions. This proactive approach to security is highly valued.

•

Access to Resources: Team members must have access to relevant training, tools, and development environments suited to their needs.

•

Security Assessment: Prior to going live, the development should be evaluated against the Security Assessment Checklist to ensure all security measures are in place.

•

Use of Proven Components: Where possible, the development team should utilise established and previously tested components to enhance security.

•

Allocation of Time for Security: Sufficient time must be allocated for security-related tasks, including research and training.

Page 6 of 21

•

Support for New Team Members: Ensure that new members receive the support they need to integrate into the team effectively.

•

Data Protection Impact Assessment (DPIA): Conduct a DPIA for all new projects or significant changes to understand the impact on personal identifiable data.

•

Secure Coding Guidelines: Security must be embedded into each phase of the SDLC, ensuring security requirements are defined at the design stage, and code reviews are conducted at each major development milestone. All software must follow OWASP Secure Coding Guidelines, and security testing must be performed before deployment.

Cultivating a Security-focused Culture •

Regular Development Meetings: These meetings should dedicate time to security discussions, review the security of developments, and provide a supportive environment for raising concerns and seeking advice.

•

Learning from Security Reviews: When security reviews identify significant concerns, it’s essential to address these with the team, facilitating sessions to learn from mistakes and providing feedback to improve future developments.

Ongoing Security Compliance •

Continual Review: Even after software release, it’s vital to conduct regular reviews due to the inevitable presence of bugs, vulnerabilities, and exploits that emerge over time.

•

Change Management: Any modifications to the code should be minimal, necessary, and go through a stringent change control process.

•

Compliance with CareCERT Notifications: Ensure all developed systems comply with CareCERT notifications for maintaining security standards.

•

Risk assessment: A formal risk assessment must be conducted before development begins. All risks must be documented in the risk register, including those related to third-party libraries and dependencies. Risk reviews must occur at each development milestone and post-release.

Requirements •

Establishing Clear Contracts: Contracts with developers or entities processing code on behalf of Provide Group must ensure reasonable protections, outlining responsibilities related to IP rights and security, including vulnerability assessments.

•

Code Escrow Considerations: Contracts should consider including provisions for code escrow to safeguard the availability of the code under specific conditions.

•

Security vetting: All third-party developers must undergo security vetting before engaging in software development for Provide CIC. Contracts must include clauses requiring compliance with ISO 27001 or equivalent standards, with periodic security audits conducted on third-party suppliers.

Managing Dependency Security •

Monitoring and Securing Dependencies: Active monitoring of all third-party libraries, plugins, and other dependencies for known security vulnerabilities is Page 7 of 21

mandatory. The development team must use tools and services designed to detect such vulnerabilities in dependencies in real time.

•

Choosing Actively Maintained Dependencies: Preference should be given to dependencies that are actively developed and maintained, ensuring they receive timely updates for security patches and improvements. This includes verifying that core dependencies and frameworks have a strong community or commercial support and a track record of addressing security issues promptly.

•

Updating Dependencies: Regularly update dependencies to the latest secure versions, incorporating this practice into the development cycle to mitigate potential security risks from outdated components.

•

Dependency Approval Process: Implement an approval process for adding new dependencies to projects, assessing their security posture, maintenance status, and compatibility with our security requirements.

•

Dependencies monitoring: All software dependencies must be continuously monitored using automated security tools. Deprecated or vulnerable dependencies must be updated immediately or removed from the project. A formal approval process is required before introducing new dependencies into production.

SLDC Frameworks To enhance the adaptability, efficiency, and security of our software development lifecycle (SDLC), Provide CIC is committed to integrating principles from Agile, Lean, and DevOps frameworks into our practices. Recognising that the specific needs and risks associated with each project may vary, we will tailor the integration of these methodologies, ensuring a flexible, streamlined, and continuous approach to security that aligns with the project's unique requirements.

•

Agile Integration: Security assessments will be iterative and synchronised with Agile sprints, focusing on embedding security within the development process from the outset. Security requirements will be integrated into user stories, ensuring they are addressed comprehensively and continuously.

•

Lean Principles Application: By applying Lean methodologies, we aim to streamline our security processes, eliminating redundancies and focusing on efficiency. This will involve a continuous improvement mindset, seeking to refine our security practices regularly.

•

DevOps Practices: We will embed security tools and automated scans within our CI/CD pipelines, ensuring that security considerations are an integral part of development and operations. This includes establishing real-time feedback mechanisms for security insights, enabling proactive responses to security issues.

Project-Specific Framework Adaptation: Understanding that each project has its own set of challenges and requirements, we will adopt a flexible approach to applying these frameworks. The emphasis on Agile, Lean, or DevOps principles will be adjusted depending on the project and software needs, ensuring the most effective and appropriate security measures are implemented.

Page 8 of 21

This strategic approach emphasises our commitment to a dynamic and responsive SLDC process. It ensures that security, efficiency, and adaptability are not just foundational elements but are also tailored to meet the specific demands of each project. Through this adaptive integration of Agile, Lean, and DevOps, we affirm our dedication to "security by design," "privacy as the default setting," "positive sum," and "end-to-end security," ensuring our software development practices are both robust and responsive to the evolving landscape.

5. Design Approach for Code When engaging in software development, it's crucial to produce code that not only meets current functional requirements but is also accessible and maintainable for future teams. This entails applying several best practices rigorously, with a strong emphasis on Privacy as the Default Setting, Full Functionality – Positive Sum, Not Zero Sum, and End-to-End Security throughout the development lifecycle: •

Self-Documenting Code: Craft clear and self-explanatory code, using meaningful names for variables and functions that illuminate their purpose, thus reducing the need for extensive commentary.

•

Version Control: Employ version control systems across all projects to document changes, enhance collaboration, and streamline code management effectively.

•

Supporting Documentation: Create in-depth documentation for intricate systems, including architectural diagrams, API documentation, and user guides, to facilitate comprehension and future development work.

•

Standardised Naming Conventions: Implement and adhere to uniform naming conventions across projects to ensure code readability and maintainability.

•

Peer Review Process: Establish a compulsory peer review process for all code alterations to improve code quality, detect bugs early, and encourage a collaborative development environment.

•

Code Reusability and Clean-up: Motivate the recycling of code where suitable, but ensure any reused code is devoid of unnecessary functionalities.

Regularly refine code to boost efficiency and readability.

•

Adherence to Secure Coding Practices: Follow secure coding guidelines, like those provided by the CERT Secure Coding project, to address potential security vulnerabilities effectively.

•

Clear Responsibility Assignment: Each code block or module should have a well-defined purpose and responsibilities, documented within the codebase or accompanying documentation.

•

Secure Credential Storage: Isolate sensitive credentials from the primary codebase using secure storage solutions, ensuring they are encrypted and managed according to the highest security practices.

•

Authorship and Authentication Controls: Maintain accurate records of code authorship. Implement robust authentication measures for accessing and modifying the codebase to assure traceability and security.

•

Integral Error Handling: Design error handling as a core component of the development process to ensure the software's robustness and resilience.

Page 9 of 21

•

Review and Approval of Changes: Mandate that all modifications, regardless of size, undergo a review process before integration into the main codebase.

•

Controlled Changes in Production: Limit direct changes in the production environment. All changes must pass through a formal change control process to guarantee stability and security.

•

Supervision and Monitoring: For any outsourced development work, Provide CIC or the contracting group company must actively oversee and monitor progress and adherence to these guidelines to ensure compliance with DSPT (where applicable) and uphold high standards of code quality and security.

Respect for User Privacy: Keeping user interests at the forefront by offering strong privacy defaults and controls, ensuring transparency about data processing purposes, and embedding data protection into the design of systems and services, we create software that is not only secure but also respects and protects user privacy.By embedding privacy into the design of systems and services and adopting a proactive and preventative approach to data protection, developers ensure that personal data is automatically protected. This strategy eliminates the need for individuals to take steps to protect their data, maintaining their privacy without action on their part. Furthermore, the commitment to full functionality assures that privacy and security are not mutually exclusive but are integrated into the development lifecycle, achieving a positive-sum outcome. End-to-end security measures are ingrained from the onset, safeguarding data throughout its entire lifecycle, thereby fostering a culture of privacy awareness and ensuring the highest standards of user-centric privacy and security

6. Secure and Compliant Development Environment The development environment is foundational to creating secure and reliable software. To uphold the highest standards of security and data integrity, the following guidelines must be strictly adhered to: Environment Segregation: Development, testing, and production environments must be distinctly separate to mitigate the risk of unauthorised access or inadvertent changes to the live system. This separation ensures that actions in one environment do not adversely affect the others, maintaining the integrity and availability of the production system.

Data Handling and Privacy: Only use fictitious or anonymized data in development and testing environments to prevent any potential data breaches and ensure compliance with data protection regulations. Real data must never be replicated in these environments to safeguard sensitive and personal information.

Environment Parity: The development and test environments should mirror the production environment as closely as possible in terms of configurations, security controls, and software versions. This parity ensures that software behaves consistently across all stages of development and deployment, reducing the risk of environment-specific issues.

Restricted Access: Limit access to the development, test, and production environments based on the principle of least privilege. Only authorised personnel should have access to these environments, and developers should not have direct

Page 10 of 21

access to the production environment. Implement strong authentication and access control measures to enforce this policy.

Secure Configuration: All environments must be securely configured to resist attacks and prevent unauthorised access. Regularly review and update the configurations to address emerging vulnerabilities and ensure compliance with the latest security standards.

Continuous Monitoring: Implement continuous monitoring tools and procedures in all environments to detect and respond to security incidents in real-time. Monitoring should cover unauthorised access attempts, changes to the environment, and potential security vulnerabilities.

Change Management: Any changes to the environment, including software updates, configuration changes, and the introduction of new tools, must go through a formal change management process. This process should include a security review to assess the impact of the changes on the overall security posture.

Developer Training: Ensure that developers and other personnel involved in the software development lifecycle are trained in secure coding practices, the importance of environment segregation, and the specific policies and procedures related to the development environment.

Compliance and Audit: Regularly audit the development, test, and production environments for compliance with this policy, industry standards, and regulatory requirements. Audits should also verify adherence to the segregation and data handling policies outlined above.

Environment Configuration: Development, testing, and production environments must be segregated to prevent unauthorised access. Strong authentication (e.g., MFA) must be enforced where possible. All development environments must have logging enabled. Sensitive development data must be encrypted at rest and in transit.

By implementing these enhanced guidelines, Provide CIC and its group companies will foster a secure, efficient, and compliant software development environment, significantly reducing the risk of security incidents and ensuring that software developed is of the highest quality and reliability.

7. Ongoing Security Compliance Maintaining the security integrity of software applications does not end upon deployment. Continuous vigilance is required to ensure that emerging threats do not compromise the software. To this end, Provide CIC and its group companies will implement the following measures for ongoing security compliance: Security Reviews: All software applications shall undergo regular security reviews to identify and mitigate vulnerabilities. These reviews will be scheduled as follows: •

Annually: A comprehensive security review of each application will be conducted annually as a minimum standard.

•

After Significant Changes: Any major updates, including new functionalities or significant system modifications, will trigger an immediate security review to Page 11 of 21

assess the impact of these changes on the application's overall security posture.

•

Post-Security Incident: Following any security incident that affects an application, a thorough review will be conducted to identify vulnerabilities exploited during the incident, with actions taken to prevent future occurrences.

Security Audit Triggers: In addition to scheduled reviews, specific conditions will prompt unscheduled security audits, including but not limited to: •

Emergence of New Threats: In response to new cybersecurity threats or vulnerabilities that could potentially affect the software.

•

Regulatory Changes: Changes in relevant laws or regulations that necessitate a review of compliance and security measures.

•

Technology Updates: Updates or changes in the technology stack or infrastructure that may introduce new vulnerabilities.

Compliance with CareCERT Notifications: Software must be reviewed in response to CareCERT notifications relevant to the technologies used or the sectors served by the software. This ensures that the software remains protected against known vulnerabilities and threats identified within the healthcare sector.

Change Control and Documentation: All changes made as a result of security reviews, audits, or in response to incidents must go through a formal change control process. This process ensures that changes are properly documented, tested, and approved before implementation. Documentation shall include details of the review or audit findings, the rationale for changes, and the impact assessment of the implemented changes.

Monitoring and Reporting: Continuous monitoring mechanisms will be implemented to detect security anomalies, breaches, or failures in real-time. A protocol for reporting these findings will be established, ensuring that all relevant stakeholders are informed and that remedial actions are promptly initiated.

Training and Awareness: Ongoing training and awareness programs will be conducted to keep development and operational teams updated on the latest security threats, trends, and best practices. This ensures that the teams are equipped to maintain and enhance the security of the software continuously.

By adhering to these guidelines, Provide CIC and its group companies commit to a proactive and dynamic approach to software security, ensuring that applications remain secure, compliant, and resilient against evolving cyber threats.

8. Consultation and Communication Effective consultation and communication are essential to maintaining and enhancing software security practices at Provide CIC and its group companies. To ensure comprehensive engagement and information sharing, the Software Development Policy, along with updates and security insights, will be distributed across the organization, supported by mechanisms for staff and stakeholders to provide feedback.

Regular training and awareness sessions will reinforce the importance of security, while stakeholder meetings will facilitate discussions on policy effectiveness and improvements. Additionally, a summary of the policy will be available to external parties Page 12 of 21

to align expectations on security standards. Engagements with external security experts and participation in industry forums will further our knowledge and adaptability to evolving security challenges. A clear incident reporting protocol will ensure swift communication and action on security incidents, with post-incident debriefs shared internally and, where necessary, externally, to foster transparency and learning.

Continuous feedback will drive the iterative improvement of the policy, ensuring it remains responsive to both internal needs and external threats, encapsulating a culture where security is a collective responsibility and a cornerstone of our operational ethos.

9. Duties Chief Executive Officer •

Holds ultimate responsibility for IT Security within Provide CIC, delegating operational tasks to the Senior Information Risk Officer (SIRO) while ensuring senior-level support for the adherence to high IT security standards throughout the Provide Group.

Director for IT & Systems •

Tasked with the formulation, management, and execution of IT security policies and processes. This role involves periodic reviews of the security policy to reflect changes in technology, threats, processes, and industry best practices, ensuring the organisation's security posture remains robust and proactive.

Technology Operations Manager •

Oversees the implementation, monitoring, and enforcement of compliance with the security policy within Provide CIC. Responsibilities include: o Providing system security guidance to staff. o Verifying that development staff possess necessary security skills. o Ensuring external parties developing on behalf of Provide CIC meet our security standards. o Conducting security reviews for all developed software prior to its deployment on Provide networks or access by Provide CIC staff. o Ensuring compliance with CareCERT notifications across all managed networks and systems.

Provide Technology Team •

Serves as the advisory body to all users on the security policy's implementation, conducting detailed security assessments of applications and software. The team's duties encompass: o Identifying vulnerabilities, recommending countermeasures, and advising IT management on software development security aspects. o Managing change requests through the Change Advisory Board. o Performing compliance checks to ensure adherence to security protocols and documentation.

Page 13 of 21

Provide Development Team •

This team plays a pivotal role in actualizing security within the development lifecycle, tasked with: o Integrating security measures from the initial stages of development to deployment and updates. o Employing secure coding practices and conducting code reviews to identify security vulnerabilities before production deployment. o Collaborating with the Technology Operations Manager and Provide Technology Team to ensure developed software meets the security assessment criteria before release. o Participating in security training sessions to stay updated on the latest threats and mitigation techniques.

Provide Group Companies Developing Software •

Companies within the Provide Group engaged in software development are required to: o Ensure their development staff are skilled and knowledgeable in security practices as outlined in the policy. o Vet and confirm the competence and policy compliance of any third parties engaged in development work. o Inform the Technology Operations Manager at the initiation of projects requiring security review. o Adhere to CareCERT recommendations and ensure compliance throughout the development lifecycle.

All Provide Group Staff •

All employees are expected to: o Comply with this security policy and related procedures. o Refrain from installing any software, including development tools, on Provide devices without express authorisation.

10. Internal Security Assessment The Provide Technology Security Team plays a crucial role in safeguarding our software development lifecycle through rigorous internal security assessments.

These assessments are designed to meticulously evaluate the security posture of our systems, ensuring they withstand current and emerging threats. To streamline this process, the team employs a scoring system that helps prioritise reviews based on the potential risk factors associated with each project. This scoring considers: •

Number of Endpoints: The more endpoints a system has, the higher its exposure to potential vulnerabilities, thus increasing the complexity of the security review.

•

Permission Layers: Systems with multiple layers of permissions or complex access control mechanisms require more in-depth analysis to prevent unauthorised access.

Page 14 of 21

•

Functionality Features: Functionalities such as accepting user inputs, document uploads, and password resets are scrutinized for vulnerabilities that could be exploited by malicious actors.

•

External Dependencies: The reliance on external code bases or applications introduces additional risks, necessitating a thorough review of these components to ensure they do not compromise the security of the overall system.

For projects with a score below a predefined threshold, a standard assessment will suffice. However, projects exceeding this threshold due to their complexity or critical nature will undergo an extensive review process.

Additionally, when external penetration testing is deemed necessary, the Provide Technology Security Team will engage with reputable providers. These providers must be selected based on official sources and recognised industry standards to conduct penetration testing. This ensures that our systems are tested against the latest techniques used by cybercriminals, providing an external perspective on our security measures' effectiveness.

This structured approach to internal security assessments enables the Provide Technology Security Team to efficiently allocate resources, ensuring that all software developments meet our stringent security standards before deployment.

Page 15 of 21

Appendix 1: Security Assessment Checklist This checklist serves as the cornerstone of our security assessments, designed to rigorously evaluate software against critical security principles. It is adaptable to address specific concerns or areas highlighted by assessors and will undergo periodic reviews to align with the latest in cybersecurity best practices, including the OWASP Top 10.

Injection Protection: • • • •

Utilise secure APIs and frameworks for data retrieval and storage, prioritising those with built-in security features.

Implement limit clauses in queries to minimise data exposure.

Sanitise all user-supplied data, preferring whitelisting to blacklisting techniques.

Unsanitised or interpolated query strings; instead, employ parameterised queries to prevent injection attacks.

Robust Authentication: • • • • • •

Eliminate default credentials and prevent the use of easily guessed administrative accounts.

Prohibit hard-coded credentials or secrets in the software codebase.

Enforce strong password policies, cross-referencing against databases of compromised passwords.

Secure account recovery processes to prevent abuse.

Implement controls to limit failed login attempts and ensure creation of a new, high-entropy session upon successful login.

Use modern and robust encryption algorithms when encrypting user passwords and signing access tokens.

Access Control: • • • • •

Implement default-deny access control policies and verify authorisation at each request.

Apply rate limiting to API endpoints and sensitive request handlers.

Log all access control failures for audit and review.

Prevent directory listings and ensure there are no accessible backup files within the application.

Make use of modern access control frameworks with explicit permission grants and suitable token expirations.

Sensitive Data Protection: • • • •

Mandate HTTPS for all data transmissions, disallowing HTTP. Employ one-way encryption for passwords, utilising contemporary hashing and salting techniques.

Disable data caching and form autocomplete on client-side for sensitive information.

Encrypt all sensitive data, both at rest and in transit, and practice data minimisation.

Page 16 of 21

Security Configuration: • • •

Ensure unnecessary services and ports are not exposed.

Keep all software components up to date and remove unnecessary components to minimise the attack surface.

Harden default accounts and application security settings.

Cross-Site Scripting (XSS) Prevention: • •

Utilise frameworks that inherently mitigate XSS vulnerabilities.

Implement content security policies to prevent XSS attacks.

Component Management: • •

Regularly audit third-party components for vulnerabilities and ensure timely updates.

Replace components that are no longer supported with secure alternatives.

Logging and Monitoring: • •

Log security-relevant events, particularly login attempts and access control failures, in a format conducive to analysis.

Regularly review logs to detect and respond to security incidents promptly.

Error Handling: • •

Display generic error messages to users, avoiding disclosure of sensitive system information.

Implement comprehensive error handling to catch and log unhandled exceptions without revealing detailed error information to the end-user.

Session Management: • • •

Use secure session tokens, with adequate length and complexity, regenerating them upon login and after privilege changes.

Implement session timeouts and provide explicit logout functionality.

Configure session cookies with "HttpOnly", "Secure", and "SameSite" attributes, limiting scope to the necessary domains.

Page 17 of 21

EQUALITY IMPACT ASSESSMENT TEMPLATE: Stage 1: ‘Screening’ Name of project/policy/strategy (hereafter referred to as “initiative”):

Software Development Policy

Provide a brief summary (bullet points) of the aims of the initiative and main activities: The initiative aims to ensure robust IT security across Provide CIC and its group companies by implementing high IT security standards, conducting regular security assessments, enforcing compliance with security policies, and promoting a culture of security awareness and continuous improvement.

Project/Policy Manager:

Director IT & Systems

Date:

This stage establishes whether a proposed initiative will have an impact from an equality perspective on any particular group of people or community – i.e. on the grounds of race (incl. religion/faith), gender (incl. sexual orientation), age, disability, or whether it is “equality neutral” (i.e. have no effect either positive or negative). In the case of gender, consider whether men and women are affected differently.

Q1. Who will benefit from this initiative? Is there likely to be a positive impact on specific groups/communities (whether or not they are the intended beneficiaries), and if so, how? Or is it clear at this stage that it will be equality “neutral”? i.e. will have no particular effect on any group.

All staff will benefit equally

Q2. Is there likely to be an adverse impact on one or more minority/under-represented or community groups as a result of this initiative? If so, who may be affected and why?

Or is it clear at this stage that it will be equality “neutral”?

Neutral

Q3. Is the impact of the initiative – whether positive or negative - significant enough to warrant a more detailed assessment (Stage 2 – see guidance)? If not, will there be monitoring and review to assess the impact over a period time? Briefly (bullet points) give reasons for your answer and any steps you are taking to address particular issues, including any consultation with staff or external groups/agencies.

N/A

Page 18 of 21

Guidelines: Things to consider Equality impact assessments at Provide take account of relevant equality legislation and include age, (i.e. young and old,); race and ethnicity, gender, disability, religion and faith, and sexual orientation.

The initiative may have a positive, negative or neutral impact, i.e. have no particular effect on the group/community.

Where a negative (i.e. adverse) impact is identified, it may be appropriate to make a more detailed EIA (see Stage 2), or, as important, take early action to redress this – e.g. by abandoning or modifying the initiative. NB: If the initiative contravenes equality legislation, it must be abandoned or modified.

Where an initiative has a positive impact on groups/community relations, the EIA should make this explicit, to enable the outcomes to be monitored over its lifespan.

Where there is a positive impact on particular groups does this mean there could be an adverse impact on others, and if so can this be justified? - e.g. are there other existing or planned initiatives which redress this?

It may not be possible to provide detailed answers to some of these questions at the start of the initiative. The EIA may identify a lack of relevant data, and that data-gathering is a specific action required to inform the initiative as it develops, and also to form part of a continuing evaluation and review process.

It is envisaged that it will be relatively rare for full impact assessments to be carried out at Provide. Usually, where there are particular problems identified in the screening stage, it is envisaged that the approach will be amended at this stage, and/or setting up a monitoring/evaluation system to review a policy’s impact over time.

Page 19 of 21

EQUALITY IMPACT ASSESSMENT TEMPLATE: Stage 2: (To be used where the ‘screening phase has identified a substantial problem/concern) This stage examines the initiative in more detail in order to obtain further information where required about its potential adverse or positive impact from an equality perspective. It will help inform whether any action needs to be taken and may form part of a continuing assessment framework as the initiative develops.

Q1. What data/information is there on the target beneficiary groups/communities?

Are any of these groups under- or over-represented? Do they have access to the same resources? What are your sources of data and are there any gaps?

Q2. Is there a potential for this initiative to have a positive impact, such as tackling discrimination, promoting equality of opportunity and good community relations? If yes, how? Which are the main groups it will have an impact on?

Q3. Will the initiative have an adverse impact on any particular group or community/community relations? If yes, in what way? Will the impact be different for different groups – e.g. men and women?

Q4. Has there been consultation/is consultation planned with stakeholders/ beneficiaries/ staff who will be affected by the initiative? Summarise (bullet points) any important issues arising from the consultation.

Q5. Given your answers to the previous questions, how will your plans be revised to reduce/eliminate negative impact or enhance positive impact? Are there specific factors which need to be taken into account?

Q6. How will the initiative continue to be monitored and evaluated, including its impact on particular groups/ improving community relations? Where appropriate, identify any additional data that will be required.

Page 20 of 21

Guidelines: Things to consider An initiative may have a positive impact on some sectors of the community but leave others excluded or feeling they are excluded. Consideration should be given to how this can be tackled or minimised.

It is important to ensure that relevant groups/communities are identified who should be consulted. This may require taking positive action to engage with those groups who are traditionally less likely to respond to consultations, and could form a specific part of the initiative.

The consultation process should form a meaningful part of the initiative as it develops, and help inform any future action.

If the EIA shows an adverse impact, is this because it contravenes any equality legislation? If so, the initiative must be modified or abandoned. There may be another way to meet the objective(s) of the initiative.

Further information: Useful Websites www.equalityhumanrights.com Website for new Equality agency www.employers-forum.co.uk – Employers forum on disability www.efa.org.uk – Employers forum on age © MDA 2007 EQUALITY IMPACT ASSESSMENT TEMPLATE: Stage One: ‘Screening’

Page 21 of 21