Information Security Policy for SafePass, Inc.

1.0 Purpose

This Information Security Policy (the “Policy”) establishes the minimum acceptable security standards for protecting all information assets owned, leased, or otherwise controlled by SafePass, Inc. (hereinafter referred to as “the organization” or “SafePass”). This Policy aims to ensure the confidentiality, integrity, and availability of information, minimizing risks and safeguarding SafePass’s reputation, operational effectiveness, and legal compliance. It applies to all individuals and entities with access to SafePass’s information systems and resources, including but not limited to employees (full-time, part-time, and temporary), contractors, consultants, interns, volunteers, third-party vendors, business partners, and guests (collectively referred to as “users”). All users are responsible for understanding and complying with this Policy.

2.0 Scope

This Policy encompasses all information assets, regardless of their location, format, or storage medium. “Information assets” include, but are not limited to:

  • Hardware: Servers, workstations, laptops, mobile devices, network equipment, printers, peripherals, and any other physical computing devices.
  • Software: Operating systems, applications, databases, utilities, and any other software programs.
  • Data: Electronic data, including customer data, financial records, intellectual property, trade secrets, business plans, marketing materials, and any other information stored or processed by SafePass.
  • Intellectual Property: Patents, trademarks, copyrights, trade secrets, and other forms of intellectual property owned or licensed by SafePass.
  • Physical Records: Paper documents, files, and other physical records containing sensitive information.

This Policy addresses all aspects of information security, encompassing administrative, physical, and technical controls designed to protect these assets from unauthorized access, use, disclosure, alteration, disruption, or destruction.

3.0 Policy Statements

3.1 Access Control:

  • Access to information systems and resources are granted on a least privilege basis, meaning users will only be granted the minimum necessary access rights required to perform their job duties. Access requests must be approved by designated authorized personnel, typically the user’s manager and the IT department.
  • Access rights are reviewed and revoked promptly upon termination of employment, change in job responsibilities, or as otherwise necessary. Regular access reviews are conducted to ensure access remains appropriate.
  • Multi-factor authentication (MFA) are implemented for all privileged accounts (e.g., system administrators, database administrators) and, where feasible and appropriate, for all other user accounts. MFA methods may include, but are not limited to, time-based one-time passwords (TOTP), hardware tokens, and biometric authentication.
  • User access is logged and monitored regularly.

3.2 Asset Management Throughout Their Lifecycle:

  • A comprehensive and up-to-date asset inventory is maintained, documenting all hardware, software, and data assets, including ownership, location, classification, and lifecycle status. This inventory is managed by the IT department.
  • Assets are managed throughout their entire lifecycle, from acquisition and procurement to deployment, maintenance, upgrades, and secure disposal. Established procedures are followed for each stage of the lifecycle.
  • Regular asset audits are conducted, at least annually, to ensure the accuracy of the asset inventory and compliance with this Policy. Discrepancies are investigated and resolved promptly.

3.3 Asset Integrity for Hardware and Software:

  • Hardware and software are protected from unauthorized modification, damage, or theft. Physical security measures, such as access controls and surveillance systems, are implemented to protect hardware.
  • Software installations are controlled and managed to prevent the introduction of malicious software. Only authorized software from trusted sources are permitted. Software licensing are strictly enforced.
  • Regular security patching and updates are applied to all hardware and software to address known vulnerabilities. A patch management process is implemented to ensure timely patching.

3.4 Access & Password Management:

  • Strong passwords are enforced for all user accounts. Passwords must meet complexity requirements (e.g., minimum length, character types), and password reuse across different systems is strictly prohibited.
  • Password change frequency is enforced. Users are required to change their passwords regularly.
  • Password management tools are encouraged to assist users in generating and managing strong, unique passwords.
  • Password policies are regularly reviewed and updated.

3.5 Application Security:

  • Secure coding practices are followed during application development to minimize vulnerabilities. Developers will receive security training.
  • Applications are thoroughly tested for vulnerabilities before deployment, including static and dynamic application security testing (SAST/DAST).
  • Regular security assessments and penetration testing are conducted on applications to identify and address potential weaknesses.

3.6 Business Continuity:

  • A comprehensive Business Continuity Plan (BCP) is developed and maintained to ensure the organization’s ability to continue essential operations during disruptions, such as natural disasters, cyberattacks, or pandemics.
  • The BCP will outline procedures for recovering critical business functions and systems within defined timeframes.
  • The BCP is tested regularly, at least annually, through simulations and exercises to validate its effectiveness and identify areas for improvement.

3.7 Change Management:

  • A formal change management process is implemented to control and track all changes to information systems and resources. This process will include change requests, approvals, implementation plans, and post-implementation reviews.
  • All changes are documented, reviewed, and approved by authorized personnel before implementation. Emergency changes are subject to expedited review and approval but will still be documented.

3.8 Configuration Management:

  • Secure configuration baselines are established for all hardware and software components. These baselines will define the secure configuration settings for each system.
  • Configuration changes are tracked and managed to prevent security vulnerabilities. Configuration management tools are used to automate configuration and ensure consistency.

3.9 Data Classification:

  • Data is classified based on its sensitivity and criticality. Common data classifications include Confidential, Internal, and Public.
  • Appropriate security controls are applied to protect data based on its classification level. Confidential data are subject to the most stringent controls.
  • Data classification is regularly reviewed and updated.

Data Classification Levels

The organization uses the following data classification levels:

  • Confidential (Highest Sensitivity): Information whose unauthorized disclosure could cause significant harm to the organization, including but not limited to: trade secrets, customer proprietary information, financial records, legal documents, strategic plans, and personnel records. Access to Confidential data is restricted to authorized personnel with a legitimate business need-to-know.
  • Restricted (High Sensitivity): Information that requires protection from unauthorized disclosure, modification, or destruction, but whose unauthorized disclosure would not cause the same level of harm as Confidential data. Examples include internal memos, project documents, and some research data. Access to Restricted data is limited to authorized personnel within specific departments or teams.
  • Internal (Moderate Sensitivity): Information intended for internal use within the organization. While not highly sensitive, it still requires appropriate handling to maintain business operations and prevent unintended disclosure. Examples include general business communications, training materials, and internal reports.
  • Public (Low Sensitivity): Information that is publicly available or intended for public release. While no specific access restrictions apply, it should still be handled responsibly. Examples include marketing materials, press releases, and publicly available reports.

Data Handling Procedures by Classification Level

The following table outlines the required handling procedures for each data classification level:

 

Classification Storage Transmission Access Control Disposal
Confidential Encrypted storage (at rest and in transit). Access control lists (ACLs) enforced. Secure physical storage for hard copies. Encrypted transmission using secure protocols (e.g., HTTPS, SFTP). Need-to-know basis. Multi-factor authentication (MFA) required for access. Regular access reviews. Secure destruction methods (e.g., shredding, data wiping).
Restricted Encrypted storage where feasible. Access control lists (ACLs) enforced. Secure physical storage for hard copies. Encrypted transmission where feasible. Need-to-know basis. Secure destruction methods.
Internal Secure storage. Standard transmission methods. Access granted based on job role. Standard disposal methods.
Public No specific storage or transmission requirements. No specific access restrictions. Standard disposal methods.

Data Labeling

All data, regardless of format, should be labeled with its appropriate classification level. For electronic documents, this can be achieved through metadata tagging or file naming conventions. For physical documents, labels should be affixed to the document or its container.

Data Owner Responsibilities

Data owners are responsible for:

  • Classifying data appropriately.
  • Defining access controls for their data.
  • Ensuring that data handling procedures are followed.
  • Reviewing data classifications periodically.

Training

All employees will receive training on this Data Classification and Handling Policy. Training will cover the different classification levels, the associated handling procedures, and the importance of data protection.

3.10 Data Encryption:

  • Sensitive data are encrypted both in transit and at rest. Encryption methods will comply with industry best practices and standards, such as AES-256.
  • Encryption keys are securely managed.

3.11 Disaster Recovery:

  • A Disaster Recovery Plan (DRP) is developed and maintained to ensure the organization’s ability to recover from a disaster that disrupts critical IT systems and infrastructure.
  • The DRP will outline procedures for restoring systems and data from backups, including recovery time objectives (RTOs) and recovery point objectives (RPOs).
  • The DRP is tested regularly, at least annually, to validate its effectiveness and ensure it meets the organization’s recovery requirements.

3.12 Identification and Detection of Cyber Threats:

  • Security monitoring tools and systems, such as Security Information and Event Management (SIEM) systems, are deployed to detect and identify cyber threats.
  • Intrusion detection and prevention systems (IDPS) are implemented to protect against malicious activity.
  • Threat intelligence feeds are used to stay informed about the latest threats and vulnerabilities.

3.13 Incident Management:

  • A formal incident management process is established to handle security incidents effectively. This process will include incident reporting, analysis, containment, eradication, recovery, and post-incident review.
  • Security incidents are reported promptly to the designated incident response team.

3.14 Incident Response:

  • An incident response plan is developed and maintained to guide the organization’s response to security incidents. The plan will outline roles and responsibilities, communication protocols, and procedures for containing and eradicating threats.
  • The incident response plan is tested regularly, through tabletop exercises and simulations, to ensure its effectiveness.

3.15 Network Security:

  • Firewalls, intrusion detection/prevention systems, virtual private networks (VPNs), and other security controls are implemented to protect the network from unauthorized access and malicious activity.
  • Network access is restricted based on the principle of least privilege. Network segmentation is used to isolate sensitive systems and data.
  • Regular network security assessments, including vulnerability scanning and penetration testing, are conducted.

3.16 Physical & Environmental Security:

  • Physical access to information systems and resources are restricted to authorized personnel. Access controls, such as key card access, biometric scanners, and security cameras, are implemented.
  • Environmental controls, such as temperature and humidity monitoring, fire suppression systems, and uninterruptible power supplies (UPS), are implemented to protect hardware.

3.17 Third Party Security Management:

  • Third-party vendors and service providers are required to meet SafePass’s security requirements. Security assessments are conducted on third-party vendors before granting them access to information systems and resources.
  • Contracts with third-party vendors will include security provisions and service level agreements (SLAs).

3.18 Vulnerability Management:

  • Regular Vulnerability Scanning: Automated vulnerability scans are conducted at least monthly on all systems and applications. These scans will utilize industry-standard tools and cover a wide range of vulnerabilities. Scans are performed both internally and externally, as appropriate.
  • Penetration Testing: Penetration testing, including both black box and grey box testing, are performed at least annually by qualified and independent third-party security professionals. These tests will simulate real-world attacks to identify and exploit security weaknesses. The scope of penetration testing is defined and agreed upon prior to each engagement.
  • Vulnerability Assessment and Prioritization: Identified vulnerabilities are assessed and prioritized based on their potential impact and likelihood of exploitation, using a standardized risk scoring system. A risk register is maintained to track identified vulnerabilities and their remediation status.
  • Remediation Process: A formal vulnerability remediation process is followed. Remediation activities are tracked and documented. Patches and updates are applied promptly following thorough testing in a non-production environment. 
  • Reporting and Metrics: Regular vulnerability reports and metrics, including the number of vulnerabilities identified, remediation timeframes, and overall risk posture.

3.19 Patch Management:

Patch Management Process:

  • A documented patch management process will be followed for all software and software services. This process includes:
  • Identification: Regularly monitoring for new patches and updates from vendors and security sources.
  • Evaluation: Assessing the criticality and potential impact of patches, including testing in a non-production environment.
  • Deployment: Deploying approved patches to production systems according to established schedules and procedures.
  • Verification: Verifying the successful installation of patches and ensuring that systems are functioning correctly.
  • Documentation: Maintaining a record of all patches applied, including the date of installation and the systems affected.

Patching Cadence based on Criticality:

  • Critical/Zero-Day Vulnerabilities: Patches for critical or zero-day vulnerabilities will be deployed as soon as they are available and thoroughly tested, ideally within 24-72 hours of release. Emergency patching procedures will be followed for these situations.
  • High Severity Vulnerabilities: Patches for high severity vulnerabilities will be deployed within [Specify timeframe, e.g., one week] of release, following testing in a non-production environment.
  • Medium Severity Vulnerabilities: Patches for medium severity vulnerabilities will be deployed within [Specify timeframe, e.g., one month] of release, after thorough testing.
  • Low Severity Vulnerabilities: Patches for low severity vulnerabilities will be bundled with other updates and deployed during regularly scheduled maintenance windows.

Version Tracking:

  • The organization will maintain an inventory of all software and software services, including version numbers.
  • Version tracking will be used to identify software that is nearing end-of-life or that requires upgrades to address security vulnerabilities.

Testing:

  • All patches and updates will be thoroughly tested in a non-production environment before being deployed to production systems.
  • Testing will include functional testing, compatibility testing, and performance testing.

Maintenance Windows:

  • Regular maintenance windows will be scheduled for deploying patches and updates.
  • Maintenance windows will be communicated to affected users in advance.

Emergency Patching:

  • Procedures will be in place for emergency patching of critical vulnerabilities outside of scheduled maintenance windows.

Patching History:

  • A patching history will be maintained for all systems and software, including the date of installation, the patches applied, and the systems affected.
  • This history will be used for auditing, reporting, and troubleshooting.

Cloud-Based Services (SaaS):

  • For cloud-based software services, the organization will work with the service provider to ensure that patching and updates are performed in a timely manner.
  • The organization will monitor the service provider’s security advisories and notifications for information about patching and updates.

Third-Party Software:

  • For third-party software, the organization will follow the vendor’s recommended patching procedures.

4.0 Data Retention

Data handling contract language included within all supplier agreements:

Data Retention

Supplier shall retain all Personal Data, Financial Records, etc. for a period of 3 years following the termination of the applicable services or as required by applicable law, whichever is longer. Supplier shall maintain appropriate records to demonstrate compliance with these retention requirements.

Data Destruction

Upon the expiration of the applicable retention period or as otherwise required by SafePass, Inc. (hereinafter referred to as “the organization”), Supplier shall securely destroy all data in its possession or control, including all copies thereof, whether in electronic or physical format. Destruction shall be performed using industry-recognized methods that render the data irretrievable. Supplier shall provide the organization with a written certification of destruction within 3 days of the data’s destruction.

Data Encryption

Supplier shall encrypt all sensitive data both in transit and at rest. Encryption in transit shall be performed using industry-standard protocols, such as TLS 1.2 or higher. Supplier shall ensure that encryption keys are securely generated, stored, and managed.

Compliance

Supplier shall comply with all applicable laws and regulations related to data retention, destruction, and encryption.

Audit Rights

The organization shall have the right to audit Supplier’s data handling practices to ensure compliance with this section.

Breach Notification

Supplier shall notify the organization within 4 hours of any actual or suspected data breach or unauthorized access. The notification shall include all available details regarding the breach, including the types of data involved, the number of individuals affected, and the steps being taken to mitigate the breach.

Flow Down

Supplier shall ensure that all subcontractors and other third-party vendors involved in the processing of all data are bound by similar data retention, destruction, and encryption requirements as set forth in this section.

6.0 System Hardening

Hardening Standards

  • All systems and devices covered by this policy must be hardened according to established configuration baselines. These baselines will be based on industry best practices, including but not limited to:
  • Center for Internet Security (CIS) Benchmarks
  • National Institute of Standards and Technology (NIST) Security Configuration Checklists
  • Vendor-recommended security hardening guides
  • Specific hardening standards will be developed and maintained for each type of system or device. These standards will address:
  • Operating system configuration
  • Application configuration
  • Network configuration
  • Firewall rules
  • Access controls
  • Patch management
  • Logging and auditing

Implementation:

  • System hardening will be implemented during the initial deployment of a system or device and will be maintained throughout its lifecycle.
  • A documented process will be followed for implementing hardening changes. This process will include:
  • Testing changes in a non-production environment
  • Documenting all changes
  • Obtaining approval from authorized personnel

Patch Management:

  • A robust patch management process will be implemented to ensure that all systems and devices are patched promptly to address known vulnerabilities.
  • Patches will be tested before deployment to avoid introducing new issues.
  • Patching schedules will be established for different types of systems and devices.

Vulnerability Scanning:

  • Regular vulnerability scans will be conducted to identify any deviations from the established hardening standards.
  • Identified vulnerabilities will be remediated promptly based on risk assessment.

Configuration Management:

  • Configuration management tools will be used to automate the hardening process and ensure consistency across all systems and devices.
  • Configuration changes will be tracked and managed to prevent unauthorized modifications.

Security Baselines:

  • Security baselines will be established for each type of system or device. These baselines will define the minimum acceptable security configuration.
  • Deviations from the security baselines will be addressed promptly.

Documentation:

  • All hardening procedures and configuration changes will be documented.
  • Documentation will be maintained and kept up-to-date.

Training:

  • All personnel responsible for managing systems and devices will receive training on system hardening procedures and this policy.

6.0 Enforcement:

Violation of this Information Security Policy may result in disciplinary action, up to and including termination of employment or contract, and may also include legal action where applicable. Specifically, failure to comply with vulnerability management procedures, including neglecting to report identified vulnerabilities or delaying remediation without proper authorization, are considered a serious offense.

7.0 Review and Updates:

This Information Security Policy is reviewed and updated at least annually, or more frequently as needed, to reflect changes in the organization’s business environment, threat landscape, regulatory requirements, or industry best practices. Notice of policy changes are communicated to all affected personnel.

8.0 Contact Information:

For questions or concerns regarding this Information Security Policy, please contact the Information Security Team at: [email protected]. For reporting security incidents, please use the dedicated incident reporting channel.