Data Protection Policy

Last Updated at 2022-Jan-05

1.1 Purpose

The purpose of this policy to ensure that customer data should not disclose to any government/public authority and third party until unless it’s necessary according to GDPR.

1.2 Scope

This policy applies to all BrainPayroll employees and all third parties responsible for the processing of personal data on behalf of BrainPayroll services/entities. The content of this policy also applies to our processors and sub processors globally.

1.3 Policy

BrainPayroll receives requests from government agencies, users and other third parties to disclose data other than in the ordinary operation and provision of the Services. This Data Request Policy outlines BrainPayroll’s policies and procedures for responding to such requests for Customer Data. Any capitalised terms used in this Data Request Policy that are not defined will have the meaning set out in the Customer Terms of Service. In the event of any inconsistency between the provisions of this Data Request Policy and the Customer Terms of Service or written agreement with the Customer, as the case may be, the Customer Terms of Service or written agreement will prevail.

1.4 Requests for Customer Data by individuals

Third parties seeking Customer Data should contact the Customer regarding such requests. The Customer controls the Customer Data and generally has the right to decide what to do with all Customer Data.

1.5 Requests for Customer Data by a legal authority

BrainPayroll is committed to the importance of trust and transparency for the benefit of our customers. Except as expressly permitted by the Contract or as described in this policy, BrainPayroll will only disclose Customer Data in response to valid legal process. BrainPayroll requires a search warrant issued by a court of competent jurisdiction or the equivalent legal process in the applicable jurisdiction to disclose the contents of Customer Data. BrainPayroll does not voluntarily disclose any data to government entities unless: (a) there is an emergency involving imminent danger of death or serious physical injury to any person, or (b) to prevent harm to the Services or Customers. BrainPayroll also does not voluntarily provide governments with access to any data about users for surveillance purposes.

• All requests by governmental entities or parties involved in litigation seeking content data associated with Customers who are under contract with BrainPayroll UK Ltd. A UK/EEA base company should be sent to dataofficer@brainpayroll.co.uk.
• All requests by government entities or parties involved in litigation seeking content data associated with Customers who are under contract with BrainPayroll UK Limited, outside of a UK/EEA, should be sent to dataofficer@brainpayroll.co.uk. These requests will be processed by personnel located in London, UK.
• All requests should include the following information: (a) the requesting party, (b) the relevant criminal or civil matter, and (c) a description of the specific Customer Data being requested, including the relevant Customer’s name and relevant Authorised User’s name (if applicable),
• Requests should be prepared and served in accordance with applicable law. All requests should be focused on the specific Customer Data sought. All requests will be interpreted narrowly by BrainPayroll, so please do not submit unnecessarily broad requests. If legally permitted, the Customer will be responsible for any costs arising from BrainPayroll’s response to such requests.

1.6 Customer notice

If a request concerns personal information for which a customer is the controller, BrainPayroll will ordinarily ask the Requesting Authority to make the Data Disclosure Request directly to the relevant Customer. If the Requesting Authority agrees, BrainPayroll will support the Customer in accordance with the terms of its contract to respond to the Data Disclosure Request.

Unless BrainPayroll is prohibited from doing so or there is a clear indication of illegal conduct or risk of harm, BrainPayroll will notify the Customer of the request before disclosing any of the Customer’s Data so that the Customer may seek legal remedies.

If BrainPayroll is legally prohibited from notifying the Customer prior to disclosure, BrainPayroll will take reasonable steps to notify the Customer of the demand after the non-disclosure requirement expires. In addition, if BrainPayroll receives legal process subject to an indefinite non-disclosure requirement, BrainPayroll will challenge that non-disclosure requirement in court.

1.7 Domestication and international requests

BrainPayroll requires that any individual or entity issuing legal process or legal information requests (e.g. discovery requests, warrants or subpoenas) ensure that the process or request is properly domesticated. For data stored in the United Kingdom, BrainPayroll does not accept legal process or requests directly from law enforcement entities outside the UK or EEA. Foreign law enforcement agencies seeking data stored within the UK should proceed through a mutual legal assistance treaty or other diplomatic or legal means to obtain data through a court where BrainPayroll is located.

Last Updated at 2022-Jan-07

1.1 Purpose

This Policy sets out the type(s) of personal data held by the Company, the period(s) for which that personal data is to be retained, the criteria for establishing and reviewing such period(s), and when and how it is to be deleted or otherwise disposed of.

1.2 Scope

This policy applies to all persons within the Company (meaning permanent, fixed term, temporary staff and sub-contractors engaged with the Company). Adherence to this policy is mandatory and non-compliance could lead to disciplinary or contractual action.

1.3 Policy

This policy sets out the obligations of “Brain Payroll UK Limited” (hereinafter referred to as the "Company") regarding retention of personal data collected, held, and processed by the Company in accordance with General Data Protection Regulation ("GDPR").

The GDPR defines "personal data" as any information relating to an identified or identifiable natural person (a "data subject"). An identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier, or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of that natural person. The Company only ever retains records and information for legitimate or legal business reasons and always complies fully with EU data protection laws, guidance and best practice.

1.4 Objectives

The GDPR impose obligations on the Company, as a Data Processor, to process personal data in a fair manner which notifies data subjects of the purposes of data processing and to retain the data for no longer than is necessary to achieve those purposes.

Summary of the Company's objectives and principles in relation to Data Retention are as follows:

• Process the personal data on client servers through Remote desktop and Virtual desktop Infrastructure (VDI).
• All of the work is done on client servers, any exception can be mentioned in the data processing agreement, and controls are in place so company staff cannot download any data on Company premises until or unless it's agreed and mandatory for processing purposes.
• Any server managed by the company, where they are responsible for the management the adequate Data Leak Prevention controls and where possible, automations are in place.
• If company receives any data from the client or download it from their servers, it's store on an encrypted (AES 128/256) storage location.
• Set out limits for the retention of personal data and ensure they are complied with
• Ensure the Company complies fully with its obligation and rights of data subjects under the GDPR
• Ensure the safe and secure disposal of confidential data and information assets
• Ensure that records and documents are retained for the legal, contractual and regulatory period stated in accordance with each bodies rules or terms.
• Mitigate against risks or breaches in relation to confidential information.
• Data Leak Prevention (DLP) controls are in place, which includes technical measures (like VDI Tools) as well as Physical measures (like no internet or camera phones are allowed with-in data processing room)

1.5 Responsibilities

Heads of departments and information asset owners have overall responsibility for the management of records and data generated by their departments' activities, namely to ensure Records Retention Policy that the records created, received and controlled within the purview of their department, and the systems (electronic or otherwise) and procedures they adopt, are managed in a way which meets the aims of this policy.

Where a DPO has been designated, they must be involved in any data retention processes and records or all archiving and destructions must be retained. Individual employees must ensure that the records for which they are responsible are complete and accurate records of their activities, and that they are maintained and disposed of in accordance with the Company's protocols.

1.6 Retention Period

• IT Department works closely with the Operations team to understand how long the data has to be stored and when it has to be deleted (in line with the work order/agreement).
• Any records or evidence of incident should be retained for at least 3 years and should be reviewed quarterly. It will be disposed by the decision of ISMS Team.
• Any records where client’s hosts the personal data, is not stored on BrainPayroll servers or office premises.
• Any records where client’s hosts the personal data, is not stored on BrainPayroll servers or office premises.

Client Data

Data Type	Retention Period	Why is it collected	Who can access	Security	Final Disposition
PII (Excel, word, pdf files)	One month	Payroll Process	Data Processing Team	Stored on encrypted location and Password protected	Secure deletion
Databas	NA	Debugging purpose	Development Team	Access though SQL Management studio	Remove the access immediately after purpose completion
Masked Database for production issue.	According to debugging time	Debugging purpose	Development Team	Data mask and download only after client’s approval. Download only on secure location by IT team, Access allows to developer team on password protected system.	Secure deletion

Payroll Application logs Information

Data Type	Retention Period	Why is it collected	Who can access	Security	Final Disposition
Payroll application logs	3 years	For investigation of incidents with third external application.	Production support team	Stored in database at UK server.	Secure deletion

Incident & Evidence

Data Type	Retention Period	Why is it collected	Who can access	Security	Final Disposition
Incident Records and Evidence	3 years	Minimize the impact on business operations	Compliance officer and management	Stored in lockable filing cabinet – CS own access to files If stored as e-copy; access will be password protected	Confidential shredding OR Safe/secure deletion

Last Updated at 2022-Jan-10

1. INTRODUCTION

BrainPayroll Security Policy Document encompasses all aspects of security, especially surrounding confidential payroll information. All company employees and contractors must understand this document in its entirety and sign the form confirming they have read and understood this policy fully. This document will be reviewed and updated by management on an annual basis or when relevant to include newly developed security standards into the policy and distribute it to all employees and contracts as applicable.

This Security Policy is a formal set of rules by which all stakeholders who are given access to the company’s technology and information assets must abide.

The main purpose is to inform company’s all stakeholders about their obligatory requirements for protecting the technology and information assets of the company.

1.1 Security goals

BrainPayroll is committed to safeguarding the confidentiality, integrity, availability, and resilience of all physical and electronic information assets of the payroll data to ensure that regulatory, operational, and contractual requirements are fulfilled. The overall goals for the BrainPayroll security requirements are below:

• Compliance with current laws, regulations, and guidelines.
• Compliance with the requirements for confidentiality, integrity, availability, and resilience for payroll data
• Protecting payroll data and information against theft, abuse and other forms of harm or loss
• Motivate administrators and employees to maintain the responsibility for, ownership of and knowledge about payroll data security, in order to minimize the risk of security incidents.
• Achieve continuing their services even if major security incidents occur.
• External service providers comply with information security needs and requirements.

1.2 Security Strategy

The current business strategy and framework for risk management are the guidelines for identifying, assessing, evaluating, and controlling information related risks through establishing and maintaining the security policy (this document).

It has been decided that information security is to be ensured by the policy for information security and a set of underlying and supplemental documents. In order to secure operations at BrainPayroll even after serious incidents, we ensure the availability of continuity plans, backup procedures, defense against damaging code and malicious activities, system and information access control, incident management and reporting.

The term security policy is related to the following concepts:

• Confidentiality:
  Information is not made available or disclosed to unauthorized individuals, entities, or processes.
• Integrity:
  Safeguarding the accuracy and completeness of information and IT assets.
• Availability:
  Being accessible and usable upon demand by an authorized entity

Most critical aspects supporting activities are availability and reliability for network, infrastructure, and services. We practice openness and principles of public disclosure, but in certain situations we prioritize confidentiality over availability and integrity.

2. APPLICATION SECURITY

The Secure Application development policy is a plan of action to guide developers’ decisions and actions to ensure software security. Development of code has been checked and validated with the most current versions of the Coding Standards for Secure Application Development. All developers verified that their code is in compliance with the most recent and approved coding standards and guidelines.

2.1 Protected Stored Data

All sensitive payroll data stored and handled protected against unauthorized use at all times. Any sensitive payroll data that is no longer required for business reasons will be discarded with an anonymized technique.

2.2 Protected Data in Transit

1. All sensitive payroll data protected if it is to be transported physically or electronically. Payroll data never be sent over the internet via email (except when initiated by customers/end users for support of live issue), instant chat or any other end-user technologies.
2. If there is a business justification to payroll data via email or via the internet or any other modes then it will be done after authorization and by using a best possible security and encryption mechanism (i.e. – AES, SSL, TLS, etc.,).
3. The transportation of media containing sensitive payroll data to another location needs to be authorized by management, logged, and inventoried.
4. Authenticate internal network communications within departments by network VLAN security.
5. Identified the BrainPayroll data, services and servers and allowed access of it by VDI solution only.
6. Screen share, clipboard, local to VDI copy past are blocked.
7. During COVID situation remote user access assigned through SSL Secure VPN.

2.3 Disposal of Stored Data

1. All data will be securely disposed of when no longer required by the Company, regardless of the media or application type on which it is stored.
2. All hard copies of payroll data must be manually destroyed as when no longer required for valid and justified business reasons. A quarterly process is in place to confirm that all non- electronic payroll data has been appropriately disposed of in a timely manner.
3. The Application allows the user to delete their own data. This operation is known as hard delete which will remove data from the database.
4. We can delete or archive data from the system if we receive a request from the subject.
5. All payroll data on electronic media will be rendered unrecoverable when deleted.
6. All payroll data awaiting destruction will be held in lockable storage containers.
7. Any data user processing by downloading in local environment wiped with 24 hours.

2.4 Password Policy

1. All users with access to payroll data have a unique ID.
2. All user uses a username and password to access the payroll data or any other electronic resources
3. A unique password must be setup for new users and the users are prompted to change the password on the first login.
4. Password expiry feature is available within the system. The default password expires policy is 45 days.
5. The process of selecting a password is complex. A strong password will be:
   • Passwords must be a combination of uppercase, lowercase alphabets, numbers, and special characters
   • Passwords must not be the same as username or of the reverse order
   • passwords must not be less than twelve characters.
   • A new user must be set to change password at first logon

2.5 Security Features

1. Data is transferred using web API which is highly secured with TLS V1.2 communication protocol with Token based authentication. Whenever any data request comes from outside it first checks the token and if it is valid then only the request will be processed. The Token is generated when the user logged in.
2. Our applications are running on an SSL Certificate which is the most secure way to perform communication between the server and client. SSL Certificate initiates a secure session with browsers, once a secure connection is established, all web traffic between the web server and the web browser will be secure.
3. Token uses the JWT concept which is the most secure way of generating tokens. (https://jwt.io/)
4. For an external user like an employee user, we are using a dedicated API for external users which returns only employee related data. This will eliminate the risk of getting access to data exposed by other APIs.
5. We are using “Token Based Authentication”, so without authentication data cannot be accessed.
6. If the token has been tampered with, it will expire login and the user will have to login again.
7. We are using the entity framework for database activity, which is highly protected against SQL Injection.
8. Connection string used to connect the database is in encrypted form, which cannot be exposed.
9. We are using stored procedures to fetch data, so SQL queries are not exposed when client server communication happens.
10. Archive data will keep data in the system, but it will not be visible or accessible by any other users.

3. SERVER SECURITY

To protect the servers against network analysis attacks, the servers are secured as follows.

3.1 Antivirus

1. We are using market leading Antivirus Security which is being updated automatically.
2. Protects enterprise against the full spectrum of sophisticated cyber threats with speed and accuracy. It is a layered next-gen architecture that delivers prevention, detection, remediation, and visibility in a single modular platform.
3. To effectively protect from highly sophisticated cyber-attacks that evade conventional endpoint security tools, a layered defense approach with multi-stage signature-less technologies, including advanced machine learning, behavioral analysis, anti-exploit, and integrated sandbox.
4. The antivirus software is cable of detecting all known types of malicious software (Viruses, Trojans, adware, spyware, worms and rootkits). All removable media (for example USB) are scanned for viruses before being used. End users cannot be able to modify and any settings or alter the antivirus software.

3.2 Patch Management Policy

Our components are updated automatically with the latest security fixes in the standard Microsoft patch cycle. Security patches have to be installed every second week of the month when it release from Microsoft.

All server components etc. have up-to-date system security patches installed to protect the asset from known vulnerabilities.

Firewall, NAS, switches, and other network components update with the latest firmware. Normally use the n-1 policy for firmware updates and prefer to use the most recent and stable version of the firmware.

3.3 Password Policy

Strong passwords on any accounts with access to Remote Desktop should be considered a required step before enabling Remote Desktop. Where possible passwords are generated using a password generation tool, which ensures that the password is difficult to remember and is stored at a secure file.

All users, including contractors and vendors with access to the systems, are responsible for taking the appropriate steps to select and secure their passwords.

2FA use to access critical devices, servers, and services access.

3.4 Vulnerability Management Policy

All the vulnerabilities would be assigned a risk ranking such as High, Medium and Low based on industry best practices.

We run internal and external network vulnerability scans after any significant change in the network.

Vulnerability scans are performed by external staff periodically and the scan process has to include that rescans will be done until passing results are obtained.

3.5 Physical Security

1. We have restricted servers from any other storage media. So, no external devices can be attached to the system until we allow.
2. Configured servers to not auto-run content from removable media such as USB tokens, drives and DVDs, etc
3. Server-room access prohibited for non-authorize users, finger base access system configured on server- room entrance.
4. UPS and DG system available to run all servers and desktop for a couple of hours in case of power failure.
5. Required cooling environment maintain in server-room for 24*7 by using multiple air-conditions.
6. Cloud server is hosted with market leading service providers.
7. We have required SLA and agreements with the hosting provider for uptime and troubleshooting issues.
8. We make sure that the hosting provider is in compliance with require certificates for the security of servers and follow proper ITSM.
9. Server hardening is in place according to server hardening policy.

3.6 Remote Access Policy

1. Secure remote access (RDP) strictly controlled. Control is enforced by two-factor authentication. Only authenticated users can access the system with permission via 2FA, to monitor all login activities.
2. IP based restriction enabled, the servers can only be accessed through authorized IPs.
3. The Server only runs network services, protocols and ports that are necessary to achieve its business purpose.
4. Client/Vendor accounts with access to the server will only be enabled during the time period the access is required and will be disabled or removed once access is no longer required.
5. Assign only require permission to VPN user. Users can access only his/her system or assigned services. All other devices access is prohibited.

3.7 Network Policy

All our cloud servers are within the UK region. The data center is totally secure, highly resilient and designed to cope with all computing demands.

1. Arbor DDoS protection is applied across the data center network. When potential threats are detected, traffic is redirected through the Arbor solution, stripping out harmful attack traffic and allowing only legitimate traffic through.
2. Our cloud provider’s UK data centers are ISO 9001, ISO 27001, ISO 22301 and PCI DSS compliant. In fact, with an impressive number of global certifications, we’re proud to say we are using Server from the UK’s most accredited cloud company.
3. All unnecessary services, protocols, ports, etc., has been disabled.
4. Interconnectivity
   • Dual-zone fire detection & suppression system
   • Diverse fiber routing via multiple carriers
   • Cross Connection to a number of Tier 1 carriers
   • Scalable architecture including multiple redundant core switches and routers

3.8 Firewall Policy

1. No direct connections from the Internet to the payroll data environment will be permitted. All traffic has to traverse through a firewall.
2. The firewall rules will be reviewed periodically to ensure validity and the firewall has clean up rule at the bottom of the rule base.
3. Web base restriction is configured to access any websites, only allowed websites or categories are accessible.
4. Security reports, unauthorized access or any malicious activity logs received daily by email notifications.
5. SSL VPN is configured to give resources access out of the office in special conditions.
6. DDOS attacks, are monitored and prevent from firewall.

4. DISASTER RECOVERY & BUSINESS CONTINUITY

We maintain best resilience practices to minimize productivity hampering and data loss. We can recover from any damage to computer equipment or files within a reasonable period of time. Each entity is required to develop and maintain a plan for responding to a system emergency or other occurrence (for example, fire, system failure and natural disaster) that damages systems. This will include developing policies and procedures to address the following

4.1 Data Backup Plan

A backup policy is a pre-defined, set schedule whereby information from business applications. Backup for user files is uploaded to the cloud server or FTP and/or tape to ensure data recoverability in the event of accidental data deletion, corrupted information or some kind of a system outage. Backup data is stored in an off-site location and protected from physical damage.

Backup policies typically consist of capturing an initial full backup of data onto a disk and/or tape, followed by a series of intervening incremental or differential daily backups.

The backups are protected through strong passwords and backups are uploaded securely to the cloud server.

4.2 Disaster Recovery Plan

A disaster recovery plan has been developed which contains a process enabling the entity to restore any loss of data in the event of a fire, natural disaster, or system failure.

4.3 SLA (Service Level Agreement)

The SLA is a contract between parties that defines the services provided, the indicators associated with these services, acceptable and unacceptable service levels, liabilities on the part of the service provider and the customer, and actions to be taken in specific circumstances.

There are certain objectives for SLA:
We facilitate two-way communication between clients. This communication starts at the beginning of the process to establish an SLA and continues throughout the life of the arrangement. The clients involved come together in order to understand each other’s needs, priorities and concerns, and to gain an insight into the problems which may be faced by each party through the failure of each party to fulfill their obligations.

5. SECURITY AWARENESS AND PROCEDURES

The policies and procedures defined below should be incorporated into company practice to maintain a high level of security awareness. The protection of sensitive data needs regular training of all employees and contractors.

Review handling procedures for sensitive data and hold periodic security awareness meetings to incorporate these procedures into day-to-day practice. Distribute this security policy document to all employees/clients to read.

Maintaining a formal security awareness program for all employees that provide multiple methods of communicating awareness and educating employees (training, meetings, documentation, etc.)

The awareness training includes; Security awareness Training, GDPR information, Secure coding guideline etc.

5.1 Audit and Log review:

The audit and Log review procedure cover all logs generated for systems within the payroll data environment including the following components:

• Operating System Logs
• Database Audit Logs
• Antivirus Logs
• Cloud Server Monitoring Logs
• Application Monitoring Logs
• End User Application access logs

The IT team has configured the Email / SMS alert for any potentially suspicious activity. Email / SMS will be sent for the alerts to the related team’s mailbox with a summary of the incident. The related team also receives details of email alerts for informational purposes.

Audit Logs maintained for a minimum of 3 months. The authorized person can only be permitted to access log files.

6. RELEASE MANAGEMENT

Release management is the process of managing, planning, scheduling, and controlling a software build through different environments and different life cycles; including testing and deploying software releases.

6.1 Change Roles

Changes to the application are managed and executed according to a formal change control process. The control process is to ensure that changes proposed are reviewed, authorized, implemented, and released in a controlled manner; and that the status of each proposed change is monitored.

The change control process is formally defined and documented. This documented process includes change management responsibilities and a change request form. The change request form contains change related details and risk calculator. The risk calculator defines the overall risk of classified changes.

The change roles are as follow:

Change Requester

• Create a new change request as they are working with incidents, problems, configuration items, and release respectively.
• Submit the change request.
• Change the status of a change request to requested or cancel the change request.

Change Manager

• Plans and tracks change request during its process.
• Sometimes responsible for creating a change request.
• Manage the members of the approver.
• Sign-off on the change request form.

Change Approver (CAB)

• Change approver consists of the group of users in the organization who approve the financial, technical, and operational impact of a request for change and do the risk assessment of changes.
• Sign-off on the change request form.

Change Implementer

• After being approved by the Change Approver, the Related team assigned tasks that are part of the implementation of a change request.

6.2 Release Automation

Deploying a software package to the production environment is fully automated. Release Automation refers to the process of packaging and deploying an application or update of an application from development, across various environments, and ultimately to production.

Having the ability to deliver a high-quality application rapidly and safely is its most important competitive differentiator. By exploring and implementing deployment automation options, DevOps and continuous delivery teams are better able to build, test, and deliver reliable applications more quickly.

Automation tool helps cultivate DevOps best practices by providing a combination of automation, environment modeling and workflow-management capabilities. These practices help teams deliver software rapidly, reliably, and responsibly. Automated tools achieve a key DevOps goal of implementing continuous delivery with a large number of releases quickly.

Automated tools deploy applications using structured release-automation techniques that allow for an increase in visibility for the whole team. It combines workload automation and release-management tools as they relate to release packages, as well as movement through different environments within the DevOps pipeline.

Automated tools help regulate deployments, how environments are created and deployed, and how and when releases are deployed.

6.3 Standard Release Process

The release process ensures that the code written by the development team is built on a build server using the build tool. Once the testing of the built package is completed and passed, it can be deployed in environments for testing or live usage. The Release process is a critical bridge between Development and Testing/Production.

There are five primary steps to the release process as follow:

Release planning

• The planning stage may be the most time intensive as this is where the entire release is structured from start to finish.
• A robust release plan helps to stay on track and ensures standards and requirements are properly met.
• Release plan includes timelines, delivery dates, requirements and the overall scope of the project.
• To map out a plan and clarify the process we have created a release process checklist. The checklist is to outline the process functions and responsibilities in roughly chronological order.
• When the team looks at the checklist, they quickly establish what step they are on and what their role and responsibility are.
• Once the plan is approved and finalized, it can be put it into action by respected leaders.

Build release

• With the release plan finalized, developers start designing and building for release. This is the actual “development” of the application based on the requirements outlined in the release plan.
• Once all the issues that may have come up are addressed, subject the build to real-world scenario testing.
• This takes several iterations. As the team builds out the product, it is sent (usually automatically) to a testing environment for user acceptance. This allows the team to identify any bugs or issues that may arise in a live environment.
• As issues are identified, the build is sent back for development at stage two. In other words, within the iterative release management process, the work may flow from stage two to stage three and back again until the release is approved.

User acceptance testing

• User acceptance testing, also known as UAT, is when the end users or client start testing and give valuable feedback. This is often done as a free beta trial online or shared with a larger group of employees.
• User acceptance testing is the most crucial step to release management because of the amount of data collected and fixes required in order to get the build to where it needs to be for the official launch.
• The build must pass through the UAT stage to be considered for final implementation and release.

Prepare release

• This step is to put the finishing touches on the product. Release preparation also includes a final quality review
• During the review, the QA team will conduct final checks to ensure the build meets the minimum acceptable standards and business requirements outlined in the release plan.
• Although UAT and quality assurance can’t always replicate every scenario that might occur once the product by the QA team is launched, these steps hopefully fleshed out the most common bugs so that team can better anticipate and prevent any problems at launch.
• Once the review is completed, the functional team will validate the findings and finalize the release for deployment. Before the build can deploy into a live environment, it must be approved by the respected leader.

Deploy release

• This step is to release the application into the production environment.
• For instance, users get notified of changes with the release and how to operate within the new features.
• Finally, during the deployment stage, the development team meets to assess the release’s performance and discuss how the deployment went.
• If there are any lingering issues, those should be identified and documented for the team to address in the next iteration.

6.4 Emergency Release Process

In the case of emergency changes that have to be dealt with by Release Planning, this general rule should never be violated: "No matter how urgent a release is, it has to pass through Release Management". It is usually done for a quick fix for a problem or known error.

Compared to Standard Release, the main difference of an Emergency Release is that it is not planned before and needs to be implemented urgently. Therefore, it requires reduced testing efforts. Often the necessary testing, documentation and monitoring agents cannot be assigned. Finally, an emergency release is not planned within overall Release Planning, therefore it forces a change in the overall planning. An Emergency Release is managed in line with the Emergency Change activities.

The main activities in the Emergency release are as follow:

• Description of the content of the emergency release.
• At least basic testing of the release (including component and integration testing).
• Documentation of the emergency release.

6.5 Source Control

Source control is the practice of tracking and managing changes to the code. Source control management (SCM) systems provide a running history of code development and help to resolve conflicts when merging contributions from multiple sources.

SCM tool allows and encourages to have multiple local branches that can be entirely independent of each other.

Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them. This requires your working tree to be clean (no modifications from the HEAD commit).

7. SCOPE, ROLES AND RESPONSIBILITY

The scope defines part of the project planning and lists the project goals, tasks, costs, deliverables, and project deadlines. It requires input from the project stakeholders, who together with project managers establish the key elements and budget. Scope of information security includes the protection of the confidentiality, integrity, and availability of the information.

7.1 Roles and Responsibility

1. Chief Security Officer (CSO) is the high-level executive directly responsible for an organization’s entire security function. CSOs are not only responsible for their organization’s physical security needs but also their digital or electronic security requirements, including computer networks.
   Maintaining a formal security awareness program for all employees that provide multiple methods of communicating awareness and educating employees (for example, posters, letters, meetings).
2. System Administrator manages user accounts and authentication, maintain a list of service provider, monitor system performance and manage backup and recovery policy. Administrator maintaining a clean and enjoyable working environment, handling external or internal communication. The administrator manages the office activities and operations to secure efficiency and compliance with company policies.
3. Service provider provides a solution and service within our scope of work. The service provider makes suggestions an opportunities or changes needed within the organization.
4. Quality Assurance (QA) is responsible for enhancing the application quality by guaranteeing the integrity, confidentiality, and availability of the system.
5. Employees responsible for keeping a complete privacy application or program that guarantees compliance with privacy needs, develops and analysis privacy policy and handles privacy risks.
6. Change Manageris the person responsible for the proper execution of the change management process, whose mission is to change requests status, lead the review board, coordinate changes and make activity report. The change Manager is also responsible to authorize and approve Major/Minor changes in the application or program.
7. CAB (Change Advisory Board) is a group of people that support the assessment, prioritization, authorization and scheduling of changes.
8. End User is any person who has been authorized to read, create, and update information from the application and program.
9. Contractor is a business owner themselves or belongs to a vendor organization. Typically, once the work is completed, you pay them for the completed tasks. Their business is to provide certain skills for another business who doesn’t have the expertise or time to do those skills themselves.

8. ACCESS CONTROL POLICY

Access Control systems are in place to protect the interest of the company computer systems by providing a safe, secure, and readily accessible environment in which to work.

Access control systems perform identification authentication and authorization of users required login credentials which can include passwords, personal identification numbers, security tokens or other authentication factors.

Multifactor authentication requires two or more authentication factors to protect access control systems.

The privilege rights (e.g. domain and local administrator, super-user and root access) are restricted and authorization provided by the IT Services and system owner.

Access to The Company IT resources and services is a unique Active directory account and complex password.

Password issuing, strength requirements, and control are managed through the formal process. Password length, complexity and expiration times are controlled through Windows Active Directory Group Policy.

Access to confidential, Restricted and Protected information is limited to authorized persons whose job responsibilities require it. Request for access permission to be granted, changed, or revoked must be made in writing.

Access control methods include login access rights, Windows share and NFTS permission, user account privileges, server and workstation access rights, firewall permission, IIS server rights and SQL database rights as necessary.

8.1 Access Server for Support

• Access to the application servers is granted to the corporate network.
• The application server is accessible only on-premises network through a dedicated server.
• The application server automatically disconnected after five minutes of inactivity.
• We are using 2FA (Two-factor authentication) via one-time password authentication or public/private keys with strong passphrases for Live Server.
• User cannot copy and paste any data from Local server to Live server.

8.2 Data Scrambling

Data scrambling is the process to remove sensitive data. It is irreversible so that data cannot be derived from the scrambled data.

The configuration process begins with the DBA defining the attributes and mapping them to database columns. Then they collect attributes together to define policies and policy sets. All these steps are part of the data scrambling configuration and are performing within the SQL database.

Updated at 2022-Jan-12

1. Purpose

The IT Security Information Breach Notification Policy defines the minimum requirements and responsibilities for reporting security incidents to minimize the negative impact on the confidentiality, integrity, and availability of BrainPayroll Information and systems.

2. Scope

This policy applies to all BrainPayroll employees and all third parties responsible for the processing of personal data on behalf of BrainPayroll services/entities. The content of this policy also applies to our processors and sub processors globally.

3. Policy Statement

This Policy requires all individuals with access to BrainPayroll Resources and Information to immediately report any suspected or actual security incidents to dataofficer@brainpayroll.co.uk

In addition, the Policy requires maintenance of a process to help identify and act on security incidents quickly and effectively, including:

• Handling of such incidents by authorized personnel to allow for proper and complete investigation.
• Cooperation with those charged with investigating security incidents to help identify required actions.
• Documentation of security incidents for record keeping.
• Availability of records for internal and external reviews.
• Engagement of the relevant and appropriate levels of university management to foster a coordinated determination of the response actions.
• An assessment on the impact of security incidents to help identify and take measures that will prevent recurrence or mitigate harm.
• Timely notice and communication as required to external bodies and affected individuals.
• Compliance with any state, federal or international laws governing security incident and data breach events.
• Expeditious handling of security incidents to facilitate the restoring of normal operations.
• Review of security incidents for any patterns and areas of risk to help improve incident handling policies and procedures.
• Periodic testing of the information security handling process to measure efficacy; and
• Delivery of awareness and training on security incident reporting and handling periodically to maintain, enhance, or reinforce understanding of these measures.

4. Breach of GDPR

• Within twenty-four (24) hours of the discovery of a GDPR Breach, the DPO, after consultation with the Office of General Counsel, will determine whether reporting to supervisory authorities and/or data subjects is required by law or is otherwise prudent.
• A determination from the DPO that notification is required and the authorization from an authorized member of management will initiate the external notification procedure. Notification to EU data protection authorities is required unless a determination is made that the Breach is unlikely to result in a risk to data subjects. If the Breach is likely to result in a High Risk to data subjects, notification to data subjects is also required.
• The DPO, after consultation with the Office of General Counsel, will determine the appropriate authorities to notify. Notification to authorities must: (i) describe the nature of the Breach including, where possible, the categories and approximate number of data subjects concerned and the categories and the approximate number of Personal Information records concerned; (ii) communicate the name and contact details of the DPO or other contact point where more information can be obtained; (iii) describe the likely consequences of the Breach; and (iv) describe the measures taken or proposed to be taken by BrainPayroll to address the Breach, including, where appropriate, measures to mitigate its possible adverse effects.
• External reporting to the EU GDPR supervisory authorities must be conducted within seventy-two (72) hours of discovery of the security incident, wherever feasible. If any delay in reporting is necessary, the reasons for this delay must be documented. In all cases, external reporting must be conducted within thirty (30) days.
• The business process owner of the compromised system/files will compile the list of the specific individuals whose GDPR Data is reasonably believed to have been accessed and/or acquired by an unauthorized person. When specific individuals cannot be identified, all individuals who are likely to have been affected, such as all whose GDPR Data is stored in the files involved, should be notified. The process for determining inclusion in the notification group must be documented.
• The DPO, after consulting with the Office of General Counsel, will determine the plan for notifying individuals affected by the Breach consistent with the following guidelines:
• The method of notification –
  • In general, notices should be sent by postal mail or, preferably, email. BrainPayroll’s standard Breach notice will consist of an email message featuring the official BrainPayroll logo, addressed to the individual at the last recorded email address registered with BrainPayroll. Any notices returned as undeliverable should be re-sent via another channel, such as by first class mail, if alternate contact information is available.
• The content of the notice –
  • The notice should include a description of the incident in general terms.
  • The notice should include a description of the type of GDPR Data that was the subject of the Breach.
  • The notice should include a description of the general acts of BrainPayroll to protect the information from further unauthorized access and/or acquisition.
  • The notice should include a telephone number that the individual may call for further information and assistance; and
  • The notice should include advice that directs the individual to remain vigilant by reviewing account statements and monitoring free credit reports, where applicable to the nature of the Breach.
• The timing of notification –
  • Affected individuals must be notified as expeditiously as possible, and without unreasonable delay, consistent with any measures necessary to determine the scope of the Breach and to restore the reasonable integrity of the data system.
  • Delay is permitted when a law enforcement agency has determined that notification will impede a criminal investigation. In such a case, notification must occur as soon as the law enforcement agency determines that notification will no longer compromise the investigation. The factors considered when determining the timing of notification must be documented.

Last Updated at 2022-Jan-17

1.1 Purpose

This Acceptable Usage Policy covers the security and use of all Brain Payroll information and IT equipment. It also includes the use of email, internet, voice and mobile IT equipment. This policy applies to all Brain Payroll’s employees, contractors and agents (hereafter referred to as ‘individuals’).

1.2 Scope

This policy applies to all information, in whatever form, relating to Brain Payroll business activities, and to all information handled by Brain Payroll relating to other organizations with whom it deals. It also covers all IT and information communications facilities operated by Brain Payroll or on its behalf.

1.3 Policy

Computer Access Control – Individual’s Responsibility

Access to the IT systems is controlled using User IDs, passwords and/or tokens. All User IDs and passwords are to be uniquely assigned to named individuals and consequently, individuals are accountable for all actions on the Brain Payroll IT systems.

Individuals must not:

• Allow anyone else to use their user ID/token and password on any Brain Payroll IT system.
• Leave their user accounts logged in at an unattended and unlocked computer.
• Use someone else’s user ID and password to access Brain Payroll IT systems.
• Leave their password unprotected (for example writing it down).
• Perform any unauthorized changes to Brain Payroll’s IT systems or information.
• Attempt to access data that they are not authorized to use or access.
• Exceed the limits of their authorization or specific business need to interrogate the system or data.
• Connect any non- Brain Payroll authorized device from Brain Payroll network or IT systems.
• Store Brain Payroll data on any non-authorized Brain Payroll equipment.
• Give or transfer Brain Payroll data or software to any person or organization outside Brain Payroll without the authority of Brain Payroll.

Respective managers must ensure that individuals are given clear direction on the extent and limits of their authority regarding IT systems and data.

Internet and Email Conditions of Use

Use of Brain Payroll internet and email is intended for business use. Personal use is permitted where such use does not affect the individual’s business performance, is not detrimental to Brain Payroll in any way, not in breach of any term and condition of employment and does not place the individual or Brain Payroll in breach of statutory or other legal obligations.

All individuals are accountable for their actions on the internet and email systems.

Individuals must not:

• Use the internet or email for the purposes of harassment or abuse.
• Use profanity, obscenities, or derogatory remarks in communications.
• Access, download, send or receive any data (including images), which Brain Payroll considers offensive in any way, including sexually explicit, discriminatory, defamatory material.
• Use the internet or email to make personal gains or conduct a personal business.
• Use the internet or email to gamble.
• Use the email systems in a way that could affect its reliability or effectiveness, for example distributing chain letters or spam.
• Place any information on the Internet that relates to Brain Payroll, alter any information about it, or express any opinion about Brain Payroll, unless they are specifically authorized to do this.
• Send unprotected sensitive or confidential information externally
• Forward Brain Payroll mail to personal non-Brain Payroll email accounts (for example a personal Gmail account).
• Make official commitments through the internet or email on behalf of Brain Payroll unless authorized to do so.
• Download copyrighted material such as music media (MP3) files, film and video files (not an exhaustive list) without appropriate approval.
• In any way infringe any copyright, database rights, trademarks or other intellectual property.
• Download any software from the internet without prior approval of the IT Department.
• Connect Brain Payroll devices to the internet using non-standard connections.

Social media applications must be accessed only for business use and as per project requirements. The afore-mentioned internet usage best practices guidelines apply for social media access as well.

Clear Desk and Clear Screen Policy

To reduce the risk of unauthorized access or loss of information, Brain Payroll enforces a clear desk and screen policy as follows:

• Personal or confidential business information must be protected using security features provided for example secure print on printers.
• Computers must be logged off/locked or protected with a screen locking mechanism controlled by a password when unattended.
• Care must be taken to not leave confidential material on printers or photocopiers.
• All business-related printed matter must be disposed of using confidential waste bins or shredders.

Working Off-Site

It is accepted that laptops and mobile devices will be taken off-site. The following controls must be applied:

• Working away from the office must be in line with Brain Payroll remote working policy.
• pEquipment and media taken off-site must not be left unattended in public places and not left in sight in a car.
• pLaptops must be carried as hand luggage when travelling.
• pInformation should be protected against loss or compromise when working remotely (for example at home or in public places).
• pCare should be taken with the use of mobile devices such as laptops, mobile phones, smartphones and tablets. They must be protected at least by a password or a PIN and, where available, encryption.
• pData access on mobile must be give with MDM. There should be no direct access of any official application and data.

Mobile Storage Devices

Mobile devices such as memory sticks, CDs, DVDs and removable hard drives must be used only in situations when network connectivity is unavailable or there is no other secure method of transferring data. Only Brain Payroll authorized mobile storage devices with encryption enabled must be used, when transferring sensitive or confidential data.

Software

Employees must use only software that is authorized by Brain Payroll on Brain Payroll computers. Authorized software must be used in accordance with the software supplier's licensing agreements. All software on Brain Payroll computers must be approved and installed by the Brain Payroll IT department.

Individuals must not:

• Store personal files such as music, video, photographs or games on Brain Payroll IT equipment.

Viruses

The IT department has implemented automated virus detection and virus software updates within the limits. All PCs have antivirus software installed to detect and remove any virus automatically.

Individuals must not:

• Remove or disable anti-virus software.
• Attempt to remove virus-infected files or clean up an infection, other than using approved Brain Payroll anti-virus software and procedures.

Telephony (Voice) Equipment Conditions of Use

Use of Brain Payroll invoice equipment is intended for business use. Individuals must not use voice facilities for sending or receiving private communications on personal matters, except in exceptional circumstances. All non-urgent personal communications should be made at an individual’s own expense using alternative means of communications.

Individuals must not:

• Use voice for conducting private business.
• Make hoax or threatening calls to internal or external destinations.
• Accept reverse charge calls from domestic or International operators, unless it is for business use.

Actions upon Termination of Contract

All Brain Payroll equipment and data, for example laptops and mobile devices including telephones, smartphones, USB memory devices and CDs/DVDs, must be returned to Brain Payroll. All Brain Payroll data or intellectual property developed or gained during the period of employment remains the property of Brain Payroll and must not be retained beyond termination or reused for any other purpose.

Monitoring and Filtering

All data that is created and stored on Brain Payroll computers is the property of Brain Payroll and there is no official provision for individual data privacy, however wherever possible Brain Payroll will avoid opening personal emails.

IT system logging will take place where appropriate, and investigations will be commenced where reasonable suspicion exists of a breach of this or any other policy. Brain Payroll has the right (under certain conditions) to monitor activity on its systems, including internet and email use, to ensure systems security and effective operation, and to protect against misuse.

Any monitoring will be carried out in accordance with audited, controlled internal processes.

It is user’s responsibility to report suspected breaches of security policy without delay to their line management, the IT department, the information security department or the IT helpdesk. All breaches of information security policies will be investigated. Where investigations reveal misconduct, disciplinary action may follow in line with Brain Payroll disciplinary procedures.