1. INTRODUCTION

BrainPayroll Security Policy Document encompasses all security aspects, especially confidential payroll information. All company employees and contractors must understand this document and sign the form confirming they have read and understood this policy thoroughly. This document will be reviewed and updated by management annually 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 by.

The primary purpose is to inform Company's all stakeholders about their obligatory requirements for protecting its technology and information assets.

1.1 Security goals

BrainPayroll is committed to safeguarding the confidentiality, integrity, availability, and resilience of all payroll data's physical and electronic information assets 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 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

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, defence against harmful 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::

It is safeguarding the accuracy and completeness of the information and IT assets.

Availability::

It is accessible and usable upon demand by an authorized entity.

The most critical aspects supporting activities are the availability and reliability of 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 measures to ensure software security. Code development has been checked and validated with the most current versions of the coding Standards for Secure Application Development. All developers verified that their code complied with the most recent and approved coding standards and guidelines.

We ensure code security by doing a vulnerability scan before the production release. Any bug or vulnerability must fix before release, and the green VAPT report is part of change management.

Third-party open libraries with the application are reviewed and scanned for vulnerability; the green scan report is part of change management.

Public-facing application is protected with Web application firewall (WAF) configured according to OWASP's top ten security controls to protect application from Broken authentication, SQL injection, Cross-site scripting, etc. Additionally, it protects the application from DDOS and bot attacks.

2.1 Protected Stored Data

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

Data in rest is protected with required security controls.

• Data disks are protected with AES 128/256-bit encryption and manage the disk redundancy by RAID configuration.
• MS SQL database is encrypted with TDE encryption, and sensitive fields within the database are encrypted using Agon 2 sault and paper techniques.
• Mogo DB is protected using disk encryption.

2.2 Protected Data in Transit

1. All sensitive payroll data is 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 issues), instant chat or any other end-user technologies
2. Suppose there is a business justification for payroll data via email, the internet, or other modes. In that case, it will be done after authorization and by using the best possible security and encryption mechanism (i.e., 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. We separated 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, data download to the local machine and local to VDI copy past are blocked.
7. Email security is maintained using a white-listing domain. Users can send emails only to authorized domains.
8. Teams' communication is maintained using the white-listing domain.
9. Remote user access was 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 removes 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 the local environment is wiped within 24 hours.

2.4 Password Policy

1. All users with access to payroll data have a unique ID.
2. All users use a username and password to access the payroll data or other electronic resources.
3. A unique password must be set up for new users, who are prompted to change the password on the first login
4. The password expiry feature is available within the system. The default password expiration policy is 90 days.
5. The process of selecting a password is complex. A strong password will be
   • Passwords must be a combination of uppercase, and 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 the password at first login.

2.5 Security Features

1. ata 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, only the request will be processed. The token is generated when the user logs in.
2. Our applications run on SSL certificates, the most secure way to communicate between the server and the 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, the most secure way to generate the token. (https://jwt.io/)
4. For an external user like an employee user, we are using a dedicated API for external users, which returns 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 data cannot be accessed without authentication.
6. If the token has been tampered with, the login will expire, and the user must log in again.
7. We are using an entity framework for database activity, which is highly protected against SQL Injection
8. The string used to connect the database is encrypted, which cannot be exposed.
9. We use 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 to any other users.

3. SERVER SECURITY

The servers are secured; To protect the servers against network analysis attacks following controls are in place.

3.1 Antivirus

1. We are using market-leading Antivirus Security which is being updated automatically.
2. Protects enterprises 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 defence approach with multi-stage signature-less technologies, including advanced machine learning, behavioural analysis, anti-exploit, and integrated sandbox.
4. Antivirus software detects all known types of malicious software (Viruses, Trojans, adware, spyware, worms and rootkits). All removable media (for example, USB) should be scanned for viruses before use. End users cannot modify 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 must be installed every second week of the month when it is released from Microsoft.

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

The latest firmware updates the firewall, NAS, switches, and other network components. Usually use the n-1 policy for firmware updates and prefer to use the most recent and stable version.

3.3 Password Policy

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

All users, including contractors and vendors with access to the systems, are responsible for selecting and securing their passwords.

2FA is used to access critical devices, servers, and services like production servers, Application support access, Office365 global admins, AWS accounts, etc.

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 infra VAPT quarterly and at the time of major changes in IT infrastructure.

Brain Application VAPT testing is done by an external Third-party yearly and during major code changes. We do the code scanning before every production release and fix the bug and vulnerabilities before release. Code VAPT green report is part of the change and release management.

Third-party open library use in an application is scanned before every production release, and fix the bug and vulnerabilities before release. Third-party open library VAPT green report is part of the change and release management.

VAPT result of any scan is shared with responsible stakeholders who review the report and mitigate the vulnerability.

We use JIRA as a vulnerability management tool to create JIRA for each vulnerability and assign it to a responsible team member.

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 it.
2. Configured servers to not auto-run content from removable media such as USB tokens, drives and DVDs, etc
3. Server-room access is prohibited for non-authorize users. The finger base access system is configured on the server-room entrance.
4. UPS and DG systems are available to run all servers and desktops for a couple of hours in case of power failure
5. Required cooling environment maintained in server-room for 24*7 by using multiple air conditions.
6. The 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 ensure that the hosting provider complies with the required certificates for the security of servers and follows proper ITSM.
9. Server hardening is in place according to the hardening server policy.
10. Our data processing team is seated in a separate cabin protected with a finger-based access control system, Metal detector and security guard.
11. No one can enter with a mobile phone or any other digital equipment in the data processing room.

3.6 Remote Access Policy

1. Secure remote access (RDP) is strictly controlled. Control is enforced by two-factor authentication. Only authenticated users can access the system with permission via 2FA.
2. The servers can only be accessed through SSL VPN.
3. The server only runs network services, protocols and ports necessary to achieve its business requirements.
4. Client/Vendor accounts with access to the server will only be enabled when the access is required and will be disabled or removed once access is no longer necessary.
5. Assign only require permission from the VPN user. Users can access only their system or assigned services. All other device access is prohibited

3.7 Network Policy

All our cloud servers are within the UK region. The data centre is secure, highly resilient and designed to handle all computing demands.

1. Arbor DDoS protection is applied across the data centre 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 centres 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 a server from the UK's most accredited cloud company.
3. All unnecessary services, protocols, ports, etc., have been disabled.
4. Interconnectivity
   • Dual-zone fire detection & suppression system
   • Diverse fibre 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 must traverse through a firewall.
2. The firewall rules will be reviewed periodically to ensure validity, and the firewall will have a clean-up rule at the bottom of the rule base
3. The web-based restriction is configured to access any websites, only allowed websites or categories are accessible.
4. Email notifications of receiving security reports, unauthorised access or malicious activity logs daily.
5. SSL VPN is configured to give resources access out of the office in special conditions.
6. DDOS attacks are monitored and prevented from the firewall.

4. DISASTER RECOVERY & BUSINESS CONTINUITY

We maintain best resilience practices to minimize productivity hampers and data loss. We can recover from any damage to computer equipment or files within a reasonable period. 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 NAS, cloud server or FTP to ensure data recoverability in the event of accidental data deletion, corrupted information or some system outage. Backup data is stored in an off-site location and protected from physical damage.

Backup policies typically capture an initial full data backup onto a disk and cloud, followed by a series of intervening incremental or differential daily backups

The backups are protected through encryption, and 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 data loss in the event of a fire, natural disaster, cyber security incident or system failure.

We have pre-defined RTO & RPO with the customer in case of any application component 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 establishing an SLA and continues throughout the life of the arrangement. The clients involved come together to understand each other's needs, priorities and concerns and to gain an insight into the problems each party may face through the failure of each party to fulfil their obligations.

5. SECURITY AWARENESS AND PROCEDURES

The policies and procedures defined below should be incorporated into company practice to maintain high-security awareness. The protection of sensitive data needs regular training for 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 an email alert for any potentially suspicious activity. An email 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 were maintained for six months on hot storage and three years on cold storage. 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 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 ensures that proposed changes are reviewed, authorized, implemented, and released in a controlled manner; and that the status o f 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 a risk calculator. The risk calculator defines the overall risk of classified changes.

The change roles are as follows:

• Change Requester
• Create a new change request as they work with incidents, problems, configuration items, and releases.
• Change the status of a change request to request or cancel the change request.
• Change Manager
• Plans and tracks change requests 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
• Sign off on the change request form.
• After approval by Change Approver, Related team assigned tasks that are part of implementing 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, and environment.

modeling and work-flow-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 increase visibility for the whole team. It combines workload automation and release-management tools related to release packages and 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 the code the development team writes 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 Process

1. The planning stage may be the most time-intensive as this is where the entire release is structured from start to finish.
2. A robust release plan helps to stay on track and ensures standards and requirements are properly met.
3. The release plan includes timelines, delivery dates, requirements and the project's overall scope.

   We have created a release process checklist to map out a plan and clarify the process. The checklist outlines the process functions and responsibilities in roughly chronological order.

4. When the team looks at the checklist, they quickly establish what step they are on and what their role and responsibility are.
5. Once the plan is approved and finalized, it can be implemented by respected leaders.

Build release

1. With the release plan finalized, developers start designing and building for release. It is the actual development of the application based on the requirements outlined in the release plan.
2. Once all the issues that may have come up are addressed, subject the build to real-world scenario testing.
3. 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 in a live environment.
4. The build is sent back for development at stage two as issues are identified. 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

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

Prepare release

1. This step is to put the finishing touches on the product. Release preparation also includes a final quality review
2. 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.
3. 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
4. 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

1. This step is to release the application into the production environment.
2. For instance, users get notified of changes with the release and how to operate within the new features.
3. Finally, during the deployment stage, the development team meet to assess the release's performance and discuss how the deployment went.
4. 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 which 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, forcing 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 follows:

1. Description of the content of the emergency release.
2. At least basic testing of the release (including component and integration testing).
3. 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. The scope of information security includes the protection of the confidentiality, integrity, and availability of the information.

7.1 Roles and Responsibility

1. Chief Information Security Officer (CISO) is the high-level executive directly responsible for an organization's security function. CISOs are responsible for their organization's physical security needs and 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, and meetings).

Maintaining a formal security awareness program for all employees that provide multiple methods of communicating awareness and educating employees (for example, posters, letters, and meetings).

2. System Administrator manages user accounts and authentication, maintains a service provider list, monitors system performance, and manages 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. The service provider provides a solution and service within our scope of work. The service provider makes suggestions and opportunities or changes needed within the organization.
4. . Quality Assurance (QA) is responsible for enhancing the application quality by guaranteeing the system's integrity, confidentiality, and availability.
5. Employees are responsible for keeping a complete privacy application or program that guarantees compliance with privacy needs, developing and analysing privacy policies and handling privacy risks.
6. Change Manager is responsible for the proper execution of the change management process, whose mission is to change the request status, lead the review board, coordinate changes and make an activity report. The change Manager is also responsible for authorizing and approving Major/Minor changes in the application or program
7. CAB (Change Advisory Board) is a group that supports the assessment, prioritization, authorization and scheduling of changes.
8. End User is anyone authorized to read, create, and update information from the application and program.

Contractor is a business owner themselves or belongs to a vendor organization. Typically, you pay them for the completed tasks once the work is completed. Their business is to provide certain skills for another business that 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's computer systems by providing a safe, secure, and readily accessible environment in which to work.

Access control systems authenticate and authorise users' required login credentials, including 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 the IT Services and system owner provide authorization.

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

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

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

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

8.2 Data Scrambling

Data scrambling is the process of removing sensitive data. It is irreversible, so 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 performed within the SQL database.