The purpose of this policy is to define procedures to onboard and offboard users to technical infrastructure in a manner that minimizes the risk of information loss or exposure.
This policy applies to all technical infrastructure within the organization.
This policy applies to all full-time and part-time employees and contractors.

Background:

In order to minimize the risk of information loss or exposure (from both inside and outside the organization), the organization is reliant on the principle of least privilege. Account creation and permission levels are restricted to only the resources absolutely needed to perform each person’s job duties. When a user’s role within the organization changes, those accounts and permission levels are changed/revoked to fit the new role and disabled when the user leaves the organization altogether.

Policy:

During onboarding:
1. Hiring Manager informs HR upon hire of a new employee.
2. HR submits a help desk ticket to IT to inform them of a new hire and their role.
3. Following predefined departmental profiles, IT creates accounts and assigns appropriate permission levels needed for that role.
4. For resources outside of the ownership of IT, the owner of each resource will review and approve account creation and the associated permissions.
5. IT works with the owner of each resource to set up the user.
During offboarding:
1. Hiring Manager notifies HR when an employee’s employment is ending.
2. HR promptly notifies IT, via ticket, with the effective date and time of the end of employment.
3. IT terminates access to email and customer facing services immediately, and will continue to remove access to other lower priority accounts throughout the business day.
When an employee changes roles within the organization:
1. Hiring Manager will inform HR of a change in role.
2. HR and IT will follow the same steps as outlined in the onboarding and offboarding procedures.
Review of accounts and permissions:
1. Quarterly, IT and HR will review accounts and permission levels for accuracy.

Accessibility Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Policy:

The Web Content Accessibility Guidelines (WCAG) defines requirements for designers and developers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA. IMPLAN Cloud is partially conformant with WCAG 2.1 level AA, and will be fully conformant with WCAG 2.1 level AA by December 2022.

We welcome your feedback on the accessibility of IMPLAN Cloud. Please let us know if you encounter accessibility barriers on IMPLAN Cloud via email at feedback@implan.com

Application Security Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Purpose and Scope:

This application security policy defines the security framework and requirements for all applications within the organization’s production environment.
This document also provides implementing controls and instructions for web application security, to include periodic vulnerability scans and other types of evaluations and assessments.
This policy applies to all applications within the organization’s production environment, as well as administrators and users of these applications; this typically includes employees and contractors.

Background:

Application vulnerabilities typically account for the largest number of initial attack vectors after malware infections. As a result, it is important that applications are designed with security in mind, and that they are scanned and continuously monitored for malicious activity that could indicate a system compromise. Discovery and subsequent mitigation of application vulnerabilities will limit the organization’s attack surface, and ensures a baseline level of security across all systems.
In addition to scanning guidance, this policy also defines technical requirements and procedures to ensure that applications are properly hardened in accordance with security best practices.

Policy:

The organization must ensure that all applications it develops and/or acquires are securely coded, configured, and managed.
The following security best practices must be considered and, if feasible, applied as a matter of the application’s security design:
1. Data handled and managed by the application must be classified in accordance with the Data Classification Policy (reference (A)).
2. Sensitive data (e.g., passwords) should not be displayed in plaintext.
3. Ensure that applications validate input properly and restrictively, allowing only those types of input that are known to be correct (e.g. cross-site scripting, buffer overflow errors, injection flaws, etc.)
4. Ensure that applications execute proper error handling so that errors will not provide detailed system information to an unprivileged user, deny service, or impair security mechanisms.
5. Where possible, authorize access to applications by affiliation, membership or employment, rather than by individual. Provide an automated review of authorizations on a regular basis, where possible.
6. Ensure that applications encrypt data at rest and in transit.
7. Implement application logging to the extent practical. Retain logs of all users and access events for at least 30 days.
8. Qualified peers conduct security reviews of code for all new or significantly modified applications; particularly, those that affect the collection, use, and/or display of confidential data. Document all actions taken.
9. Implement a change management process for changes to existing software applications.
10. Standard configuration of the application must be documented.
11. Default passwords used within the application, such as for administrative control panels or integration with databases must be changed immediately upon installation.
12. Applications must require complex passwords in accordance with current security best practices (at least 8 characters in length, combination of alphanumeric upper/lowercase characters and symbols).
13. During development and testing, applications must not have access to live data.
Where applications are acquired from a third party, such as a vendor:
1. Only applications that are supported by an approved vendor shall be procured and used.
2. Full support contracts must be arranged with the application vendor for full life-cycle support.
3. No custom modifications may be applied to the application without confirmation that the vendor can continue to provide support.
4. Updates, patches and configuration changes issued by the vendor shall be implemented as soon as possible after testing in a non-production environment.
5. A full review of applications and licenses shall be completed at least annually, as part of regular software reviews.
Web applications must be assessed according to the following criteria:
1. New or major application releases must have a full assessment prior to approval of the change control documentation and/or release into the production environment.
2. Third-party or acquired applications must have a full assessment prior to deployment.
3. Software releases must have an appropriate assessment, as determined by the organization’s Information Security Manager (ISM) as defined within the Security Incident Response Policy, with specific evaluation criteria based on the security risks inherent in the changes made to the application’s functionality and/or architecture.
4. Emergency releases may forego security assessments and carry the assumed risk until a proper assessment can be conducted. Emergency releases must be approved by the Chief Information Officer or designee.
Vulnerabilities that are discovered during application assessments must be mitigated based upon the following risk levels, which are based on the Open Web Application Security Project (OWASP) Risk Rating Methodology (reference (B)):
1. High – issues categorized as high risk must be fixed immediately; otherwise alternate mitigation strategies must be implemented to limit exposure before deployment. Applications with high risk issues are subject to being taken off-line or denied release into the production environment.
2. Medium – issues categorized as medium risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled. Applications with medium risk issues may be taken off-line or denied release into the production environment based on the number of issues; multiple issues may increase the risk to an unacceptable level. Issues may be fixed in patch releases unless better mitigation options are present.
3. Low – issues categorized as low risk must be reviewed to determine specific items to be mitigated. Actions to implement mitigations must be scheduled.
Testing is required to validate fixes and/or mitigation strategies for any security vulnerabilities classified as Medium risk or greater.
The following security assessment types may be leveraged to perform an application security assessment:
1. Full – composed of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide (reference (C)). A full assessment must leverage manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered issues.
2. Quick – consists of an automated scan of an application for, at a minimum, the OWASP Top Ten web application security risks (reference (D)).
3. Targeted – verifies vulnerability remediation changes or new application functionality.
4. To counter the risk of unauthorized access, the organization maintains a Data Center Security Policy (reference (E)).
5. Security requirements for the software development life cycle, including system development, acquisition and maintenance are defined in the Software Development Lifecycle Policy (reference (F)).
6. Security requirements for handling information security incidents are defined in the Security Incident Response Policy (reference (G)).
7. Disaster recovery and business continuity management policy is defined in the Disaster Recovery Policy (reference (H)).
8. Requirements for information system availability and redundancy are defined in the System Availability Policy (reference (I)).

Appendix A: References

Data Classification Policy
OWASP Risk Rating
OWASP Testing Guide
OWASP Top Ten Risk
Cloud Storage and BYOD Policy
SDLC policy
Incident Response Policy
Disaster Recovery Policy
System Availability Policy

Authorized User Password Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Purpose and Scope:

The Password Policy describes the procedure to select and securely manage passwords.
This policy applies to authorized users of IMPLAN products; an authorized user is any user that has signed up for an account or had one created for them by IMPLAN personnel
This policy applies to authorized users whose user accounts are stored within the IMPLAN managed user database

Background:

IMPLAN uses Auth0 for user authentication and management.

Policy:

Creation requirements
1. Create passwords with no fewer than 8 characters, which include characters in three of the four following categories:
  1. Upper case letters
  2. Lower case letters
  3. Numbers
  4. Special characters
  5. A password history of five passwords is enforced. Authorized users may not use a password that is one of their past five.
Password storage
1. Authorized user passwords are stored in the user database provided by Auth0
2. Passwords are encrypted with bcrypt
3. Passwords are salted and hashed
4. IMPLAN employees never have access to authorized user passwords
Password resets
1. Password resets can initiated from sign in portal, reachable from https://implan.com
Multi Factor Authentication (MFA) is available for all authorized users.
1. MFA must use a one-time pass authenticator, such as Google Authenticator
Single Sign-on
1. Single Sign-on is provided by IMPLAN as an option to the IMPLAN Cloud.
2. Customers authenticating to IMPLAN’s products using their organization’s user store will be governed by the organization’s password policies

Availability Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Purpose and Scope:

The purpose of this policy is to define requirements for proper controls to protect the availability of the organization’s information systems.
This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily available to all users.

Background:

The intent of this policy is to minimize the amount of unexpected or unplanned downtime (also known as outages) of information systems under the organization’s control. This policy prescribes specific measures for the organization that will increase system redundancy, introduce failover mechanisms, and implement monitoring such that outages are prevented as much as possible. Where they cannot be prevented, outages will be quickly detected and remediated.
Within this policy, an availability is defined as a characteristic of information or information systems in which such information or systems can be accessed by authorized entities whenever needed

Policy:

Information systems must be consistently available to conduct and support business operations.
Information systems must have a defined availability classification, with appropriate controls enabled and incorporated into development and production processes based on this classification.
System and network failures must be reported promptly to the organization’s lead for Information Technology (IT) or designated IT operations manager.
Users must be notified of scheduled outages (e.g., system maintenance) that require periods of downtime. This notification must specify the date and time of the system maintenance, expected duration, and anticipated system or service resumption time.
Prior to production use, each new or significantly modified application must have a completed risk assessment that includes availability risks. Risk assessments must be completed in accordance with the Risk Assessment Policy.
Capacity management and load balancing techniques must be used, as deemed necessary, to help minimize the risk and impact of system failures.
Information systems must have an appropriate data backup plan that ensures:
1. All sensitive data can be restored within a reasonable time period.
2. Full backups of critical resources are performed on at least a weekly basis.
3. Incremental backups for critical resources are performed on at least a daily basis.
4. Backups and associated media are retained for at least one (1) year, or in accordance with legal and regulatory requirements.
5. Backups are stored off-site with multiple points of redundancy and protected using encryption and key management.
6. Tests of backup data must be conducted once per quarter. Tests of configurations must be conducted twice per year.
7. Information systems must have appropriate redundancy and disaster recovery plans to ensure uptime meets the Service Level Agreement.
Information systems must have an appropriate business continuity plan that meets the following criteria:
1. Recovery time and data loss limits are defined in Table 1.
2. Recovery time requirements and data loss limits must be adhered to with specific documentation in the plan.
3. Company and/or external critical resources, personnel, and necessary corrective actions must be specifically identified.
4. Specific responsibilities and tasks for responding to emergencies and resuming business operations must be included in the plan.
5. All applicable legal and regulatory requirements must be satisfied.

Table 1:

Availability Classification	Availability Requirements	Scheduled outage	Recovery Time Requirements	Data Loss or Impact Loss
High	High to Continuous	30 minutes	1 hour	Minimal
Medium	Standard	2 hours	4 hours	Some data loss is tolerated if it results in quicker resolution
Low	Limited Availability	4 hours	Next business day	Some data loss is tolerated if it results in quicker resolution

Business Continuity Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Purpose and Scope:

The purpose of this policy is to ensure that IMPLAN establishes objectives, plans and procedures such that a major disruption to IMPLAN’s key business activities is minimized.
This policy applies to all infrastructure and data within IMPLAN’s information security program.
This policy applies to all management, employees, and suppliers that are involved in decisions and processes affecting IMPLAN’s business continuity. This policy must be made readily available to all whom it applies to.

Background:

The success of IMPLAN is reliant upon the preservation of critical business operations and essential functions used to deliver key products and services. The purpose of this policy is to define the criteria for continuing business operations for IMPLAN in the event of a disruption. Specifically, this document defines:
1. The structure and authority to ensure business resilience of key processes and systems.
2. The requirements for efforts to manage through a disaster or other disruptive event when the need arises.
3. The criteria to efficiently and effectively resume normal business operations after a disruption.
Within this document, the following definitions apply:
1. Business impact analysis/assessment – an exercise that determines the impact of losing the support of any resource to an enterprise, establishes the escalation of that loss over time, identifies the minimum resources needed to return to a normal level of operation, and prioritizes recovery of processes and the supporting system.
2. Disaster recovery plan – a set of human, physical, technical, and procedural resources to return to a normal level of operation, within a defined time and cost, when an activity is interrupted by an emergency or disaster.
3. Recovery time objective – the amount of time allowed for the recovery of a business function or resource to a normal level after a disaster or disruption occurs.
4. Recovery point objective – determined based on the acceptable data loss in the case of disruption of operations.

Policy:

Business Risk Assessment and Business Impact Analysis
1. Each manager is required to perform a business risk assessment and business impact analysis for each key business system within their area of responsibility.
2. The business risk assessment must identify and define the criticality of key business systems and the repositories that contain the relevant and necessary data for the key business system.
3. The business risk assessment must define and document the Disaster Recovery Plan (DRP) for their area of responsibility. Each DRP shall include:
  1. Key business processes.
  2. Applicable risk to availability.
  3. Prioritization of recovery.
  4. Recovery Time Objectives (RTOs).
  5. Recovery Point Objectives (RPOs).
Disaster Recovery Plan
1. Each key business system must have a documented DRP to provide guidance when hardware, software, or networks become critically dysfunctional or cease to function (short and long term outages).
2. Each DRP must include an explanation of the magnitude of information or system unavailability in the event of an outage and the process that would be implemented to continue business operations during the outage. Where feasible, the DRP must consider the use of alternative sites or hosting locations.).
3. Each plan must be reviewed against IMPLAN’s strategy, objectives, culture, and ethics, as well as policy, legal, statutory and regulatory requirements.
4. Each DRP must include:
  1. An emergency mode operations plan for continuing operations in the event of temporary hardware, software, or network outages.
  2. A recovery plan for returning business functions and services to normal operations.
  3. Procedures for periodic testing, review, and revisions of the DRP for all affected business systems, as a group and/or individually.
Data Backup and Restoration Plans
1. Each system owner must implement a data backup and restoration plan.
2. Each data backup and restoration plan must identify:
  1. The data custodian for the system.
  2. The backup schedule of each system.
  3. Where digital backups are to be stored and secured, as well as how access is maintained.
  4. Appropriate restoration procedures to restore key business system data from digital backup to the system.
  5. The restoration testing plan and frequency of testing to confirm the effectiveness of the plan.
  6. The method for restoring encrypted backup media.

Cloud Storage and BYOD Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Purpose and Scope:

This cloud storage and Bring Your Own Device (BYOD) policy defines the objectives, requirements and implementing instructions for storing data on removable media, in cloud environments, and on personally-owned devices, regardless of data classification level.
This policy applies to all information and data within IMPLAN’s information security program, as well as all removable media, cloud systems and personally-owned devices either owned or controlled by IMPLAN.
This policy applies to all users of information systems within IMPLAN. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by IMPLAN (hereinafter referred to as “users”). This policy must be made readily available to all users.

Background:

This policy defines the procedures for safely using cloud storage and personally-owned devices to limit data loss or exposure. Such forms of storage must be strictly controlled because of the sensitive data that can be stored on them. Because each of these storage types are inherently ephemeral or portable in nature, it is possible for IMPLAN to lose the ability to oversee or control the information stored on them if strict security standards are not followed.
This document consists of two sections pertaining to cloud storage, and personally-owned devices. Each section contains requirements and implementing instructions for the registration, management, maintenance, and disposition of each type of storage.
Within this policy, the term sensitive information refers to information that is classified as RESTRICTED or CONFIDENTIAL in accordance with the Data Classification Policy (reference (a)).

Policy:

Cloud Storage
1. All cloud storage systems in active use and containing data pertinent to IMPLAN must be registered in the cloud storage manifest. Registration may be accomplished by manual or automated means.
2. All cloud storage systems listed in the cloud storage manifest must be re-inventoried on a quarterly basis to ensure that it is still within the control of IMPLAN. To re-inventory an item, the owner of the cloud storage system must check in the item with IMPLAN’s Information Security Manager (ISM) as defined within the Security Incident Response Policy. Re-inventory may be accomplished by manual or automated means.
3. The owner of the cloud storage system must conduct all appropriate maintenance on the system at regular intervals to include system configuration, access control, performance monitoring, etc.
4. Data on cloud storage systems must be replicated to at least one other physical location. Depending on the cloud storage provider, this replication may be automatically configured.
5. IMPLAN must only use cloud storage providers that can demonstrate, either through security accreditation, demonstration, tour, or other means that their facilities are secured, both physically and electronically, using best practices.
6. If the cloud storage system contains sensitive information, that information must be encrypted in accordance with the Encryption Policy.
7. Data must be erased from cloud storage systems using a technology and process that is approved by the ISM.
8. When use of a cloud storage system is discontinued, the system owner must inform the ISM so that it can be removed from the cloud storage manifest.
Personally-owned Devices
1. Organizational data that is stored, transferred or processed on personally-owned devices remains under IMPLAN’s ownership, and IMPLAN retains the right to control such data even though it is not the owner of the device.
2. The ISM is responsible for conducting overall management of personally-owned devices, to include:
3. Personally-identifiable information (PII) may not be stored, processed or accessed at any time on a personally-owned device.
4. Users of personally owned devices are to follow the guidelines defined in the internal Acceptable Use Policy
5. IMPLAN must reserve the right to view, edit, and/or delete any organizational information that is stored, processed or transferred on the device.
6. IMPLAN must reserve the right to perform full deletion of all of its data on the device if it considers that necessary for the protection of company-related data, without the consent of the device owner.
7. IMPLAN will not pay the employees (the owners of BYOD) any fee for using the device for work purposes.
8. IMPLAN will pay for any new software that needs to be installed for company use.
9. All security breaches related to personally-owned devices must be reported immediately to the ISM

Code of Conduct Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

The purpose of this policy is to define expected behavior from employees towards their colleagues, supervisors, and the overall organization.
We expect all employees to follow our Code of Conduct. Offensive behavior, disruptive behavior, and participation in serious disputes should be avoided. Employees are expected to foster a respectful and collaborative environment.
This policy applies to all employees. They are bound by their acknowledgement of the Employee Handbook to follow the Code of Conduct Policy while performing their duties.

Policy:

To provide an effective, efficient work environment that protects the interests and safety of all personnel, IMPLAN expects professional, courteous and ethical behavior from all employees. It is not possible to list all forms of behavior that are considered unacceptable in the workplace. The following are examples of infractions of rules of conduct that may result in disciplinary action, up to and including termination of employment. The list is not conclusive:

- Theft or inappropriate removal or possession of property
- Falsification of employment records including but not limited to; employment application, resume, timekeeping, any and all other employment records
- Fighting or threatening violence in the workplace
- Boisterous or disruptive activity in the workplace
- Negligence or improper conduct leading to damage of employer- owned or customer- owned property
- Insubordination or other disrespectful conduct
- Violation of safety or health rules
- Unlawful or unwelcome harassment of any kind
- Possession of dangerous or unauthorized materials such as explosives or firearms in the workplace
- Excessive absenteeism or any absence without notice
- Unauthorized disclosure of business “secrets” including all confidential information
- Violation of personnel policies
- Unsatisfactory performance or conduct
- Illegal copying or distribution of IMPLAN Group LLC software, data and/ or its documentation

Confidentiality Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

This policy outlines expected behavior of employees to keep confidential information about clients, partners, and IMPLAN secure.
This policy applies to all employees, board members, investors, and contractors, who may have access to confidential information. This policy must be made readily available to all whom it applies to.

Background:

IMPLAN’s confidential information must be protected for two reasons:
1. It may be legally binding (i.e. sensitive customer data)
2. It may be fundamental to our business (i.e. business processes)
Common examples of confidential information in IMPLAN includes, but is not limited to:
1. Unpublished financial information
2. Customer/partner/vendor/external party data
3. Patents, formulas, new technologies, and other intellectual property
4. Existing and prospective customer lists
5. Undisclosed business strategies including pricing & marketing
6. Materials & processes explicitly marked as “confidential”
Employees will have varying levels of authorized access to confidential information.

Policy:

Employee procedure for handling confidential information
1. Lock and secure confidential information at all times
2. Safely dispose (i.e. shred) documents when no longer needed
3. View confidential information only on secure devices
4. Disclose information only when authorized and necessary
5. Do not use confidential information for personal gain, benefit, or profit
6. Do not disclose confidential information to anyone outside IMPLAN or to anyone within IMPLAN who does not have appropriate privileges
7. Do not store confidential information or replicates of confidential information in unsecured manners (i.e. on unsecured devices)
8. Do not remove confidential documents from IMPLAN’s premises unless approved by senior management.
Offboarding measures
1. The Hiring Manager should confirm the off-boarding procedure has been completed by the final date of employment.
Confidentiality measures
1. IMPLAN will take the following measures to ensure protection of confidential information:
  1. Store and lock paper documents
  2. Encrypt electronic information and implement appropriate technical measures to safeguard databases
  3. Require employees to sign non-disclosure/non-compete agreements
  4. Consult with senior management before granting employees access to certain confidential information
Exceptions
1. Under certain legitimate conditions, confidential information may need to be disclosed. Examples include:
  1. If a regulatory agency requests information as part of an audit or investigation
  2. If IMPLAN requires disclosing information (within legal bounds) as part of a venture or partnership
2. In such cases, the employee must request and receive prior written authorization from senior management before disclosing confidential information to any third parties.
Disciplinary consequences
1. Employees who violate the confidentiality policy will face disciplinary and possible legal action.
2. A suspected breach of this policy will trigger an investigation. Intentional violations will be met with termination and repeated unintentional violations may also face termination.
3. This policy is binding even after the termination of employment.

Data Classification Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

This data classification policy defines the requirements to ensure that information within the organization is protected at an appropriate level.
This document applies to the entire scope of the organization’s information security program. It includes all types of information, regardless of its form, such as paper or electronic documents, applications and databases, and knowledge or information that is not written.
This policy applies to all individuals and systems that have access to information kept by the organization.

Background:

Policy:

If classified information is received from outside the organization, the person who receives the information must classify it in accordance with the rules prescribed in this policy. The person thereby will become the owner of the information.
If classified information is received from outside the organization and handled as part of business operations activities (e.g., customer data on provided cloud services), the information classification, as well as the owner of such information, must be made in accordance with the specifications of the IMPLAN Terms and Conditions of Use and other legal requirements.
When classifying information, the level of confidentiality is determined by:
1. The value of the information, based on impacts identified during the risk assessment process. More information on risk assessments is defined in the Risk Assessment Policy.
2. Sensitivity and criticality of the information, based on the highest risk calculated for each information item during the risk assessment.
3. Legal, regulatory and contractual obligations.

Table 2: Information Confidentiality Levels

Confidentiality Level	Label	Classification Criteria	Access Restrictions
Public	For Public Release	Making the information public will not harm IMPLAN, its clients, or its partners in any way	Information is available to the public
Internal Use	Internal Use	Unauthorized access may cause minor damage or inconvenience to IMPLAN, its clients, or its partners	Information is available to all employees and authorized third parties
Restricted	Restricted	Unauthorized access to information may cause considerable damage to IMPLAN, its clients, or its parties and their reputations	Information is available to a specific group of employees and authorized third parties
Confidential and Client Data	Confidential	Unauthorized access to information or client data may cause catastrophic damage to IMPLAN, its clients, or its parties and their IMPLAN’s reputations	Information is available only to specific individuals

Information must be classified based on confidentiality levels as defined above.
Information and information system owners should try to use the lowest confidentiality level that ensures an adequate level of protection, thereby avoiding unnecessary production costs.
Information classified as “Restricted” or “Confidential” must be accompanied by a list of authorized persons in which the information owner specifies the names or job functions of persons who have the right to access that information.
Information classified as “Internal Use” must be accompanied by a list of authorized persons only if individuals outside the organization will have access to the document.
Information and information system owners must review the confidentiality level of their information assets every five years and assess whether the confidentiality level should be changed. Wherever possible, confidentiality levels should be lowered.
For cloud-based software services provided to customers, system owners under the company’s control must also review the confidentiality level of their information systems after service agreement changes or after a customer’s formal notification. Where allowed by service agreements, confidentiality levels should be lowered.
Information must be labeled according to the following:
1. Paper documents: the confidentiality level is indicated by the filing cabinet in which the document is stored. If a document is not stored in a locked cabinet, its default classification is Internal Use.
2. Electronic documents: the confidentiality level is indicated on the top and bottom of each document page. If a document is not labeled, its default classification is Internal Use.
3. Information systems: We have a manifest of databases that contain customer data (or Client Data as defined in the IMPLAN Terms and Conditions of Use)
4. Electronic mail: the confidentiality level is indicated in the first line of the email body. If it is not labeled, its default classification is “Internal Use”.
5. Electronic storage media (disks, memory cards, etc.): the confidentiality level must be indicated on the top surface of the media. If it is not labeled, its default classification is “Internal Use”.
6. Information transmitted orally: the confidentiality level should be mentioned before discussing information during face-to-face communication, by telephone, or any other means of oral communication.
All persons accessing classified information must follow the guidelines listed in Appendix A, “Handling of Classified Information.”
All IMPLAN employees are under a general NDA and may access confidential information as their job permits. All employees go through PII security and handling training, and as a result, know that this information is only to be accessed as their job demands and it must remain confidential.

Appendix A: Handling of Classified Information

Information and information systems must be handled according to the following guidelines:

Paper Documents
1. Internal Use
  1. Only authorized persons may have access.
  2. If sent outside the organization, the document must be sent as registered mail.
  3. Documents may only be kept in rooms without public access.
  4. Documents must be removed expeditiously from printers and fax machines.
2. Restricted
  1. The document must be stored in a locked cabinet.
  2. Documents may be transferred within and outside the organization only in a closed envelope.
  3. If sent outside the organization, the document must be mailed with a return receipt service.
  4. Documents must immediately be removed from printers and fax machines.
  5. Only the document owner may copy the document.
  6. Only the document owner may destroy the document.
3. Confidential
  1. The document must be stored in a locked cabinet specifically used for confidential information.
  2. The document may be transferred within and outside the organization only by a trustworthy person in a closed and sealed envelope.
  3. Faxing the document is not permitted.
  4. The document may be printed only on restricted printers..
Electronic Documents
1. Internal Use
  1. Only authorized persons may have access.
  2. When documents are exchanged via unencrypted file sharing services such as FTP, they must be password protected.
  3. Access to the information system where the document is stored must be protected by a strong password.
  4. The screen on which the document is displayed must be automatically locked after 10 minutes of inactivity.
2. Restricted
  1. Only persons with authorization for this document may access the part of the information system where this document is stored.
  2. When documents are exchanged via file sharing services of any type, they must be encrypted.
  3. Only the document owner may erase the document.
3. Confidential
  1. The document must be stored in encrypted form.
  2. The document may only be shared via file sharing services that are encrypted such as HTTPS and SSH. Further, the document must be encrypted and protected with a strong password when transferred.
Information Systems
1. Internal Use
  1. Only authorized persons may have access.
  2. Access to the information system must be protected by a strong password.
  3. The screen must be automatically locked after 10 minutes of inactivity.
  4. The information system may be only located in rooms with controlled physical access.
2. Restricted
1. 1. 1. Users must log out of the information system if they have temporarily or permanently left the workplace.
    2. Data must be erased only with an algorithm that ensures secure deletion.
2. 1. Confidential
3. 1. Access to the information system must be controlled through multi-factor authentication (MFA).
  2. The information system may only be located in rooms with controlled physical access and identity control of people accessing the room.
Electronic Mail
1. Internal Use
  1. Only authorized persons may have access.
  2. The sender must carefully check the recipient.
  3. All rules stated under “information systems” apply.
2. Restricted
  1. Email must be encrypted if sent outside the organization.
3. Confidential
  1. Email must be encrypted.
Electronic Storage Media
1. Internal Use
  1. Only authorized persons may have access.
  2. Media or files must be password protected.
  3. If sent outside the organization, the medium must be sent as registered mail.
  4. The medium may only be kept in rooms with controlled physical access.
2. Restricted
  1. Media and files must be encrypted.
  2. Media must be stored in a locked cabinet.
  3. If sent outside the organization, the medium must be mailed with a return receipt service.
  4. Only the medium owner may erase or destroy the medium.
3. Confidential
  1. Media must be stored in a specific locked cabinet.
  2. Media may be transferred within and outside the organization only by a trustworthy person and in a closed and sealed envelope.
Information Transmitted Orally
1. Internal Use
  1. Only authorized persons may have access to information.
  2. Unauthorized persons must not be present in the room when the information is communicated.
2. Restricted
  1. The room must be sound-proof.
  2. The conversation must not be recorded.
3. Confidential
  1. Conversation conducted through electronic means must be encrypted.
  2. No transcript of the conversation may be kept.

In this document, controls are implemented cumulatively, meaning that controls for any confidentiality level imply the implementation of controls defined for lower confidentiality levels – if stricter controls are prescribed for a higher confidentiality level, then only such controls are implemented.

Data Retention Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

This data retention policy defines the objectives and requirements for data retention within IMPLAN.
This policy covers all data within IMPLAN’s custody or control, regardless of the medium the data is stored in (electronic form, paper form, etc.) Within this policy, the medium which holds data is referred to as information, no matter what form it is in.
This policy applies to all users of information systems within IMPLAN. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information IMPLAN owns or controls (hereinafter referred to as “users”). This policy must be made readily available to all users.

Background:

IMPLAN is bound by multiple legal, regulatory and contractual obligations with regard to the data it retains. These obligations stipulate how long data can be retained, and how data must be destroyed. Examples of legal, regulatory and contractual obligations include laws and regulations in the local jurisdiction where IMPLAN conducts business, and contracts made with employees, clients, service providers, partners and others.
IMPLAN may also be involved in events such as litigation or disaster recovery scenarios that require it to have access to original information in order to protect IMPLAN’s interests or those of its employees, clients, service providers, partners and others. As a result, IMPLAN may need to archive and store information for longer thanit may be needed for day-to-day operations.

Policy:

Information Retention
1. Retention is defined as the maintenance of information in a production or live environment which can be accessed by an authorized user in the ordinary course of business.
2. In relation to IMPLAN Cloud, active use is defined as the length of any active subscription.
3. User data used in the development, staging, and testing of systems shall not be copied into production or live environments.
4. In relation to IMPLAN Cloud, and by default, the retention period of information shall be no shorter than one (1) year.
5. After the active use period of information is over, information will continue to be retained for no less than one (1) year.
6. At any point, either during active use or after, should a client require that data be destroyed from the live environment, they must put in a request to their Customer Service Manager or via support@implan.com.
7. Each business unit is responsible for the information it creates, uses, stores, processes and destroys, according to the requirements of this policy. The responsible business unit is considered to be the information owner.
8. IMPLAN’s leadership or legal counsel may issue a litigation hold to request that information relating to potential or actual litigation, arbitration or other claims, demands, disputes or regulatory action be retained in accordance with instructions from the legal counsel.
9. Each employee and contractor affiliated with the company must return information in their possession or control to IMPLAN upon separation and/or retirement.
10. Information owners must enforce the retention, archiving and destruction of information, and communicate these periods to relevant parties.
Information Backups
1. 1. Digital information pertaining to any web application produced or managed by IMPLAN shall have daily backups created.
  2. Digital backups will be encrypted.
  3. Digital backups will be tested quarterly.
  4. Digital backups will be retained for no less than one calendar year.
Information Archiving
1. Archiving is defined as secured storage of information such that the information is rendered inaccessible by unauthorized users in the ordinary course of business but can be retrieved by an authorized user.
2. The default archiving period of information shall be 7 years unless an approved exception permits a longer or shorter period. Exceptions must be requested by the information owner.
3. Information must be destroyed (defined below) at the end of the elapsed archiving period.
Information Destruction
1. Destruction is defined as the physical or technical destruction sufficient to render the information contained in the document irretrievable by ordinary commercially-available means.
2. IMPLAN must maintain and enforce a detailed list of approved destruction methods appropriate for each type of information archived, whether in physical storage media such as CD-ROMs, DVDs, backup tapes, hard drives, mobile devices, portable drives or in database records or backup files. Physical information in paper form must be shredded using an authorized shredding device; waste must be periodically removed by approved personnel.
Retention and archival periods for information that is created, processed, stored and used by IMPLAN is defined internally.

Datacenter Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

The purpose of this policy is to define security standards assessed when evaluating data centers.
This policy covers any cloud hosted providers and facilities that are labeled as or function as data center

Policy:

When evaluating a data center, the following security measures must be addressed:
1. Redundancy
2. Availability
3. Employee and third-party data center access
4. Access monitoring
5. Intrusion detection
6. Media destruction
7. Operational support systems (power, climate, fire, etc.)
8. Equipment maintenance and management
9. Third party security attestation (SOC compliance, ISO 9001 & 27001 compliance, etc.)
Data centers sufficiently offering coverage for the above will be considered as potential host locations.
The following locations are classified by the organization as secure areas and are governed by this policy:
1. Amazon Web Services

Disaster Recovery Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

The purpose of this policy is to define IMPLAN’s procedures to recover Information Technology (IT) infrastructure and IT services within set deadlines in the case of a disaster or other disruptive incident. The objective of this plan is to complete the recovery of IT infrastructure and IT services within a set Recovery Time Objective (RTO).
This policy includes all resources and processes necessary for service and data recovery, and covers all information security aspects of business continuity management.
This policy applies to all management, employees and suppliers that are involved in the recovery of IT infrastructure and services within IMPLAN. This policy must be made readily available to all whom it applies to.

Background:

This policy defines the overall disaster recovery strategy for IMPLAN. The strategy describes IMPLAN’s Recovery Time Objective (RTO), which is defined as the duration of time and service level for critical business processes to be restored after a disaster or other disruptive event, as well as the procedures, responsibility and technical guidance required to meet the RTO. This policy also lists the contact information for personnel and service providers that may be needed during a disaster recovery event.
The following conditions must be met for this plan to be viable:
1. All equipment, software and data (or their backups/failovers) are available in some manner.
2. If an incident takes place at IMPLAN’s physical location, all resources involved in recovery efforts are able to be transferred to an alternate work site (such as their home office) to complete their duties.
3. The Director of Infrastructure and Technology is responsible for coordinating and conducting a bi-annual (at least) rehearsal of this continuity plan.
This plan does not cover the following types of incidents:
1. Incidents that affect clients or partners but have no effect on IMPLAN’s systems; in this case, the client must employ their own continuity processes to make sure that they can continue to interact with IMPLAN and its systems.
2. Incidents that affect cloud infrastructure suppliers at the core infrastructure level, including Amazon Web Services. IMPLAN depends on such suppliers to employ their own continuity processes.

Policy:

Relocation
1. If the organization’s primary work site is unavailable, all employees required for the restoration of service have the ability to work remotely and will be expected to work from their home offices or alternate accommodations of their own choosing.
IMPLAN’s Recovery Time Objective (RTO) is 12 hours. Relocation and restoration of critical services and technologies must be completed within this time period.
Critical Services, Key Tasks and, Service Level Agreements (SLAs)
1. The following services and technologies are considered to be critical for business operations, and must immediately be restored:
  1. RingCentral
  2. Zendesk
  3. Salesforce
  4. Blackthorn
  5. Quickbooks
2. The following services and technologies are critical for the functionality of IMPLAN Cloud, and must be restored to meet the RTO, either through troubleshooting the issue or relocation to a failover datacenter:
  1. Amazon Aurora
  2. Amazon Elasticache
  3. Amazon Redshift and Redshift Data API
  4. AWS Elastic Beanstalk
  5. AWS Lambda
Notification of Plan Initiation
1. The following personnel must be notified when this plan is initiated:
  1. Justin Helmig, CEO; Erik Garrett, Vice President of Product and Technology (VPPT); Candi Clouse, VP of Customer Success; Sandy Boone, Controller; Dan Cain, VP of Sales; Michelle Jereb, Director of Marketing
2. Doug Kolpien, Director of Infrastructure and Technology is responsible for notifying the personnel listed above.
Plan Deactivation
1. This plan must only be deactivated by Doug Kolpien, Director of Infrastructure and Technology; Erik Garrett, VP.
2. In order for this plan to be deactivated, all relocation activities and critical service / technology tasks as detailed above must be fully completed and/or restored. If IMPLAN is still operating in an impaired scenario, the plan may still be kept active at the discretion of Doug Kolpien or Erik Garrett.
3. The following personnel must be notified when this plan is deactivated:
  1. Justin Helmig, CEO; Erik Garret, Vice President of Product and Technology; Candi Clouse, VP of Customer Success; Sandy Boone, Controller; Dan Cain, VP of Sales; Michelle Jereb, Director of Marketing
IMPLAN must endeavor to restore its normal level of business operations as soon as possible.
During a crisis, it is vital for certain recovery tasks to be performed right away. The following actions are pre-authorized in the event of a disaster recovery event:
1. VPPT and DIT must take all steps specified in this disaster recovery plan in order to recover IMPLAN’s information technology infrastructure and services.
2. VPPT and DIT are authorized to make urgent purchases of equipment and services.
3. VPPT and DIT are authorized to delegate communication with clients.
4. VPPT and DIT are authorized to cooperate with Amazon Web Services.
Specific recovery steps for information systems infrastructure and services are recorded in internal documentation.

Encryption Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

This policy defines organizational requirements for the use of cryptographic controls, as well as the requirements for cryptographic keys, in order to protect the confidentiality, integrity, authenticity and nonrepudiation of information.
This policy applies to all systems, equipment, facilities and information within the scope of IMPLAN’s information security program.
All employees, contractors, part-time and temporary workers, service providers, and those employed by others to perform work on behalf of IMPLAN having to do with cryptographic systems, algorithms, or keying material are subject to this policy and must comply with it.

Background:

This policy defines the high level objectives and implementation instructions for IMPLAN’s use of cryptographic algorithms and keys. It is vital that IMPLAN adopt a standard approach to cryptographic controls across all work centers in order to ensure end-to-end security, while also promoting interoperability. This document defines the specific algorithms approved for use, requirements for key management and protection, and requirements for using cryptography in cloud environments.

Policy:

IMPLAN must protect individual systems or information by means of cryptographic controls
Cryptographic keys must be protected against loss, change or destruction by applying appropriate access control mechanisms to prevent unauthorized use and backing up keys on a regular basis.
When required, clients of IMPLAN’s cloud-based software or platform offering must be able to obtain information regarding:
1. The cryptographic tools used to protect their information.
2. Any capabilities that are available to allow cloud service clients to apply their own cryptographic solutions.
3. The identity of the countries where the cryptographic tools are used to store or transfer cloud service clients’ data.
The use of organizationally-approved encryption must be governed in accordance with the laws of the country, region, or other regulating entity in which users perform their work. Encryption must not be used to violate any laws or regulations including import/export restrictions. The encryption used by IMPLAN conforms to international standards and U.S. import/export requirements, and thus can be used across international boundaries for business purposes.
All key management must be performed using software that automatically manages access control, secure storage, backup and rotation of keys. Specifically:
1. The key management service must provide key access to specifically-designated users, with the ability to encrypt/decrypt information and generate data encryption keys.
2. The key management service must provide key administration access to specifically-designated users, with the ability to create, schedule delete, enable/disable rotation, and set usage policies for keys.
3. The key management service must store and backup keys for the entirety of their operational lifetime.
4. The key management service must rotate keys at least once every 12 months.
Except where otherwise stated, keys must be managed by their owners.

Incident Reporting Policy

Reviewed: 9/25/2024

Updated: 9/25/2024

Purpose and Scope:

This security incident response policy is intended to establish controls to ensure detection of security vulnerabilities and incidents, as well as quick reaction and response to security breaches.
This document also provides implementing instructions for security incident response, to include definitions, procedures, responsibilities, and performance measures (metrics and reporting mechanisms).
This policy applies to all users of information systems within IMPLAN. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by IMPLAN (hereinafter referred to as “employees”). This policy must be made readily available to all employees.

Background:

A key objective of IMPLAN’s Information Security Program is to focus on detecting information security weaknesses and vulnerabilities so that incidents and breaches can be prevented wherever possible. IMPLAN is committed to protecting its employees, clients, and partners from illegal or damaging actions taken by others, either knowingly or unknowingly. Despite this, incidents and data breaches may happen; when they do, IMPLAN is committed to rapidly responding to them, which may include identifying, containing, investigating, resolving , and communicating information related to the breach.
This policy requires that all employees report any perceived or actual information security vulnerability or incident as soon as possible using the contact mechanisms prescribed in this document. In addition, IMPLAN must employ automated scanning and reporting mechanisms that can be used to identify possible information security vulnerabilities and incidents. If a vulnerability is identified, it must be resolved within a set period of time based on its severity. If an incident is identified, it must be investigated within a set period of time based on its severity. If an incident is confirmed as a breach, a set procedure must be followed to contain, investigate, resolve, and communicate information to employees, customers, partners and other stakeholders.
Within this document, the following definitions apply:
1. Information Security Vulnerability: a vulnerability in an information system, information system security procedure, or administrative control that could be exploited to gain unauthorized access to information or to disrupt critical processing.
2. Information Security Incident: a suspected, attempted, successful, or imminent threat of unauthorized access, use, disclosure, breach, modification, or destruction of information; interference with information technology operations; or significant violation of information security policy.
3. Information Security Manager (ISM): the role responsible for the overall security of Information Systems at IMPLAN, including both internal systems and customer facing systems, such as IMPLAN Cloud. Currently, this role is handled by the Director of Infrastructure and Technology.

Policy:

All employees must report any system vulnerability, incident, or event pointing to a possible incident to the ISM as quickly as possible but no later than 24 hours. Incidents must be reported by sending an email message to security@implan.com with details of the incident.
Employees must be trained on the procedures for reporting information security incidents or discovered vulnerabilities, and their responsibilities to report such incidents. Failure to report information security incidents shall be considered to be a security violation and will be reported to the Human Resources (HR) Manager.
Information and artifacts associated with security incidents (including but not limited to files, logs, and screen captures) must be preserved in the event that they need to be used as evidence of a crime.
All information security incidents must be responded to through the incident management procedures defined below.
In order to appropriately plan and prepare for incidents, IMPLAN must review incident response procedures at least once per year for currency, and update as required.
The incident response procedure must be tested on at least twice per year
The incident response logs must be reviewed once per month to assess response effectiveness.

Procedure For Establishing Incident Response System:

Assign an Information Security Manager (ISM) responsible for managing incident response procedures.
Define notification channel to alert the ISM of a potential security incident. Establish a company resource that includes up to date contact information for ISM.
Distribute Procedure For Executing Incident Response to all staff and ensure up-to-date versions are accessible in a dedicated company resource.
Require all staff to complete training for Procedure For Executing Incident Response at least twice per year.

Procedure For Executing Incident Response:

When an information security incident is suspected, identified or detected, employees must notify the ISM within 2 hours. The following information must be included as part of the notification:
1. Description of the incident
2. Date, time, and location of the incident
3. Person who discovered the incident
4. How the incident was discovered
5. Known evidence of the incident
6. Affected system(s)
Within 24 hours of the incident being reported, the ISM shall conduct a preliminary investigation and risk assessment to review and confirm the details of the incident. If the incident is confirmed, the ISM must assess the impact to IMPLAN and assign a severity level, which will determine the level of remediation effort required:
1. High: the incident is potentially catastrophic to IMPLAN or its clients and/or disrupts IMPLAN’s day-to-day operations; a violation of legal, regulatory or contractual requirements is likely.
2. Medium: the incident will cause harm to one or more business units within IMPLAN and/or will cause delays to a business unit’s activities.
3. Low: the incident is a clear violation of organizational security policy, but will not substantively impact the business.
The ISM, in consultation with IMPLAN leadership, shall determine appropriate incident response activities in order to contain and resolve incidents.
The ISM must take all necessary steps to preserve forensic evidence (e.g. log information, files, images) for further investigation to determine if any malicious activity has taken place. All such information must be preserved and provided to law enforcement if the incident is determined to be malicious.
Within 24 hours of the confirmation of the incident, the ISM must work with the customer success managers of all impacted clients to draft and issue communication regarding the incident. The communication must include:
1. General description of incident, including area of impact
2. Steps taken to mitigate or resolve the incident
3. Current resolution status
4. Potential impact of incident
5. Plans of future follow up communications
If the incident is deemed as High, the ISM must work with IMPLAN leadership, General Counsel, and HR Manager to create and execute a communications plan that communicates the incident to all clients.
The ISM must take all necessary steps to resolve the incident and recover information systems, data, and connectivity. All technical steps taken during an incident must be documented in IMPLAN’s incident log, and must contain the following:
1. Description of the incident
2. Incident severity level
3. Root cause (e.g. source address, website malware, vulnerability)
4. Evidence
5. Mitigations applied (e.g. patch, re-image)
6. Status (open, closed, archived)
7. Disclosures (parties to which the details of this incident were disclosed to, such as customers, vendors, law enforcement, etc.)
After an incident has been resolved, the ISM must conduct a post mortem that includes root cause analysis and documentation of any lessons learned.
Depending on the severity of the incident, the Chief Executive Officer (CEO) may elect to contact external authorities, including but not limited to law enforcement, private investigation firms, and government organizations as part of the response to the incident.
The ISM must notify all employees of the incident, conduct additional training if necessary, and present any lessons learned to prevent future occurrences. Where necessary, the HR Manager must take disciplinary action if a user’s activity is deemed as malicious.

Information Security Policy

Reviewed: 9/25/2024

Updated: 9/25/2024

Purpose and Scope:

This information security policy defines the purpose, principles, objectives and basic rules for information security management.
This document also defines procedures to implement high level information security protections within IMPLAN, including definitions, procedures, responsibilities and performance measures (metrics and reporting mechanisms).
This policy applies to all users of information systems within IMPLAN. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by IMPLAN (hereinafter referred to as “users”). This policy must be made readily available to all users.

Background:

This policy defines the high level objectives and implementation instructions for IMPLAN’s information security program. It includes IMPLAN’s information security objectives and requirements; such objectives and requirements are to be referenced when setting detailed information security policy for other areas of IMPLAN. This policy also defines management roles and responsibilities for IMPLAN’s Information Security Management System (ISMS). Finally, this policy references all security controls implemented within IMPLAN.
Within this document, the following definitions apply:
1. Confidentiality: a characteristic of information or information systems in which such information or systems are only available to authorized entities.
2. Integrity: a characteristic of information or information systems in which such information or systems may only be changed by authorized entities, and in an approved manner.
3. Availability: a characteristic of information or information systems in which such information or systems can be accessed by authorized entities whenever needed.
4. Information Security: the act of preserving the confidentiality, integrity, and availability of information and information systems.
5. Information Security Management System (ISMS): the overall management process that includes the planning, implementation, maintenance, review, and improvement of information security.

Policy:

Managing Information Security
IMPLAN’s main objectives for information security include the following:
1. IMPLAN’s objectives for information security are in line with IMPLAN’s business objectives, strategy, and plans.
2. Objectives for individual security controls or groups of controls are proposed by the IMPLAN Leadership, and others as appointed by the CEO; these security controls are approved by the CEO in accordance with the Risk Assessment Policy .
3. All objectives must be reviewed at least once per year.
4. The company will measure the fulfillment of all objectives. The measurement will be performed at least once per year. The results must be analyzed, evaluated, and reported to the management team.
Information Security Requirements
1. This policy and the entire information security program must be compliant with legal and regulatory requirements as well as with contractual obligations relevant to IMPLAN.
2. All employees, contractors, and other individuals subject to IMPLAN’s information security policy must read and acknowledge all information security policies.
3. The process of selecting information security controls and safeguards for IMPLAN is defined in the Risk Assessment Policy.
4. IMPLAN prescribes guidelines for remote workers as part of the Remote Access Policy .
5. To verify the appropriateness of a cloud service provider, IMPLAN maintains a Data Center Security Policy (reference (c)).
6. Security requirements for the software development life cycle, including system development, acquisition and maintenance are defined in the Software Development Lifecycle Policy.
7. Security requirements for handling information security incidents are defined in the Security Incident Response Policy.
8. Disaster recovery and business continuity management policy is defined in the Disaster Recovery Policy.
9. Requirements for information system availability and redundancy are defined in the System Availability Policy.

Log Management Policy

Reviewed: 9/25/2024

Updated: 9/25/2024

Purpose and Scope:

This log management and review policy defines specific requirements for information systems to generate, store, process, and aggregate appropriate audit logs across IMPLAN’s entire environment in order to provide key information and detect indicators of potential compromise.
This policy applies to all information systems within IMPLAN’s production network.
This policy applies to all employees, contractors, and partners of IMPLAN that administer or provide maintenance on IMPLAN’s production systems. Throughout this policy, these individuals are referred to as system engineers.

Background:

In order to measure an information system’s level of security through confidentiality, integrity, and availability, the system must collect audit data that provides key insights into system performance and activities. This audit data is collected in the form of system logs. Logging from critical systems, applications, and services provides information that can serve as a starting point for metrics and incident investigations. This policy provides specific requirements and instructions for how to manage such logs.

Policy:

All production systems within IMPLAN shall record and retain audit-logging information that includes the following information:
1. Activities performed on the system.
2. The user or entity (i.e. system account) that performed the activity, including the system that the activity was performed from.
3. The file, application, or other object that the activity was performed on.
4. The time that the activity occurred.
5. The tool that the activity was performed with.
6. The outcome (e.g., success or failure) of the activity.
Specific activities to be logged must include, at a minimum:
1. Information (including authentication information such as usernames or passwords) is created, read, updated, or deleted.
2. Accepted or initiated network connections.
3. User authentication and authorization to systems and networks.
4. Granting, modification, or revocation of access rights, including adding a new user or group; changing user privileges, file permissions, database object permissions, firewall rules, and passwords.
5. System, network, or services configuration changes, including software installation, patches, updates, or other installed software changes.
6. Startup, shutdown, or restart of an application.
7. Application process abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit or threshold (such as CPU, memory, network connections, network bandwidth, disk space, or other resources), the failure of network services such as DHCP or DNS, or hardware fault.
8. Detection of suspicious and/or malicious activity from a security system such as an Intrusion Detection or Prevention System (IDS/IPS), anti-virus system, or anti-spyware system.
Unless technically impractical or infeasible, all logs must be aggregated in a central system so that activities across different systems can be correlated, analyzed, and tracked for similarities, trends, and cascading effects. Log aggregation systems must have automatic and timely log ingest, event and anomaly tagging and alerting, and ability for manual review.
Logs must be manually reviewed on a regular basis:
1. The activities of users, administrators and system operators must be reviewed on at least a monthly basis.
When using an outsourced cloud environment, logs must be kept on cloud environment access and use, resource allocation and utilization. Logs must be kept for all administrators and operators performing activities in cloud environments.
All information systems within IMPLAN must synchronize their clocks by implementing Network Time Protocol (NTP) or a similar capability. All information systems must synchronize with the same primary time source.

Office Security Policy

Reviewed: 9/25/2024

Updated: 9/25/2024

Purpose and Scope:

This policy establishes the rules governing controls, monitoring, and removal of physical access to company’s facilities.
This policy applies to all staff, contractors, or third parties who require access to any physical location owned, operated, or otherwise occupied by IMPLAN.

Policy:

Key access & card systems
1. The following policies are applied to all facility access cards, keyfobs, and keys:
  1. Employees should use only the keyfob that has been assigned to them
  2. In the event of a lost keyfob, the employee should notify Human Resources or the Director of Infrastructure and Technology. Once notified, that keyfob will be disabled and, should the situation require, a new one will be issued.
Staff & contractor access procedure
1. Access to physical locations is granted to employees and contractors based on individual job function and will be granted by Human Resources.
2. Any individual granted access to physical spaces will be issued a physical key or access key card. Key and card issuance is tracked by Human Resources and will be periodically reviewed.
3. In the case of termination, Human Resources should ensure immediate revocation of access (i.e. collection of keys, access cards, and any other asset used to enter facilities) through the offboarding procedure.
Visitor & guest access procedure
1. The following policies are applied to identification & authorization of visitors and guests:
  1. Visitors and guests must be accompanied by an IMPLAN staff member while on the premises.
Audit controls & management
1. Documented procedures and evidence of practice should be in place for this policy. Acceptable controls and procedures include:
  1. New employee procedure
  2. Termination of employment procedure
  3. Log review and notification procedure
Enforcement
1. Employees, contractors, or third parties found in violation of this policy (whether intentional or accidental) may be subject to disciplinary action, including:
  1. Restricted or removed access

Open Source Software Components Policy

Reviewed: 9/25/2024

Updated: 9/25/2024

Purpose and Scope:

Using open source software (OSS) components accelerates development, improves maintainability, and reduces time to market; however certain open source licenses carry the risk of contaminating proprietary software with copyleft terms that require openly sharing the software, not being able to use for commercial use, etc.

Background:

The Open Source Software License Policy ensures that the team is empowered to use components to deliver a better platform, security, customer experience, and time to market while eliminating the risk of open source contamination.

Policy:

All Open Source Software components shall be licensed under a commercially friendly, non copyleft, open source license. Acceptable licenses include:
1. BSD
2. Apache
3. MIT
4. ICS
Unacceptable licenses include but are not limited to:
1. GPL
2. LGPL
3. MS-RL
Any licenses not listed above must be approved by the VP of Products and Technology or the CEO and must be documented in the open source content list.

Password Policy

Reviewed: 9/25/2024

Updated: 9/25/2024

Purpose and Scope:

The Password Policy describes the procedure to select and securely manage passwords.
This policy applies to all employees, contractors, and any other personnel who have an account on any system that resides at any company facility or has access to the company network.

Policy:

Creation requirements
1. Create passwords with at least 8 characters, both lowercase and capitalized, including at least one special character, one number, and spaces where supported by underlying application capability
Rotation requirements
1. All system-level passwords should be rotated on at least a quarterly basis. All employee passwords at the user-level should be rotated at least every six months.
2. If a credential is suspected of being compromised, the password in question should be rotated immediately and the Infrastructure team should be notified.
Password protection
1. All passwords are treated as confidential information and should not be shared with anyone. If you receive a request to share a password, deny the request and contact the system owner for assistance in provisioning an individual user account.
2. Do not write down passwords, store them in emails, electronic notes, or mobile devices, or share them over the phone. It is considered best practice to store every password generated for work purposes within IMPLAN’s approved password manager. If you truly must share a password, do so through a designated password manager.
3. Do not use the “Remember Password” feature of applications and web browsers.
4. If you suspect a password has been compromised, rotate the password immediately and notify engineering/security.
Enforcement
1. An employee or contractor found to have violated this policy may be subject to disciplinary action.

Policy Training Policy

Reviewed: 9/25/2024

Updated: 9/25/2024

Purpose and Scope:

This policy addresses policy education requirements for employees and contractors.
This policy applies to all full-time employees, part-time employees, and contractors. Adherence to assigned policies is binding under their Employment Offer Letter and/or Independent Contractor Agreement.

Policy:

Upon hire of a new employee or contractor, the Hiring Manager or Director of Infrastructure and Technology will determine which subsets of policies will apply to that individual. The individual will have one week to read the assigned policies. The individual will sign an acknowledgement stating which policies they have reviewed, which will be stored with their other employee documentation. Employees will receive training when pertinent policies are added or updated via video, audio, and/or documentation.

Remote Access Policy

Reviewed: 9/25/2024

Updated: 9/25/2024

Purpose and Scope:

The purpose of this policy is to define requirements for connecting to IMPLAN’s systems and networks from remote hosts, including personally-owned devices, in order to minimize data loss/exposure.
This policy applies to all users of information systems within IMPLAN. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by IMPLAN (hereinafter referred to as “users”). This policy must be made readily accessible to all users.

Background:

The intent of this policy is to minimize IMPLAN’s exposure to damages which may result from the unauthorized remote use of resources, including but not limited to: the loss of sensitive, company confidential data and intellectual property; damage to IMPLAN’s public image; damage to IMPLAN’s internal systems; and fines and/or other financial liabilities incurred as a result of such losses.
Within this policy, the following definitions apply:
1. Mobile computing equipment: includes portable computers, mobile phones, smart phones, memory cards and other mobile equipment used for storage, processing and transfer of data.
2. Remote host: is defined as an information system, node or network that is not under direct control of IMPLAN.
3. Telework: the act of using mobile computing equipment and remote hosts to perform work outside IMPLAN’s physical premises. Teleworking does not include the use of mobile phones.

Policy:

Security Requirements for Remote Hosts and Mobile Computing Equipment
1. Caution must be exercised when mobile computing equipment is placed or used in uncontrolled spaces such as vehicles, public spaces, hotel rooms, meeting places, conference centers, and other unprotected areas outside IMPLAN’s premises.
2. When using remote hosts and mobile computing equipment, users must take care that information on the device (e.g. displayed on the screen) cannot be read by unauthorized persons if the device is being used to connect to IMPLAN’s systems or work with IMPLAN’s data.
3. Employee workstations must be updated and patched for the latest security updates on at least a monthly basis.
4. Remote hosts must have endpoint protection software (e.g. malware scanner) installed and updated at all times.
5. Persons using mobile computing equipment are responsible for regular backups of organizational data that resides on the device.
6. Access to IMPLAN’s systems must be done through an encrypted and authenticated VPN connection. All users requiring remote access must be provisioned with VPN credentials from IMPLAN’s information technology team.
7. Information stored on mobile computing equipment must be encrypted using hard drive full disk encryption.
Security Requirements for Telework
1. All employees are authorized for telework.
2. Only a device’s assigned owner is permitted to use remote nodes and mobile computing equipment. Unauthorized users (such as others living or working at the location where telework is performed) are not permitted to use such devices.
3. Users performing telework are responsible for the appropriate configuration of the local network used for connecting to the Internet at their telework location.
4. Users performing telework must protect IMPLAN’s intellectual property rights, either for software or other materials that are present on remote nodes and mobile computing equipment.

Risk Assessment Policy

Reviewed: 9/26/2024

Updated: 9/26/2024

Purpose and Scope:

The purpose of this policy is to define the methodology for the assessment and treatment of information security risks within IMPLAN, and to define the acceptable level of risk as set by IMPLAN’s leadership.
Risk assessment and risk treatment are applied to the entire scope of IMPLAN’s information security program, and to all assets which are used within IMPLAN or which could have an impact on information security within it.
This policy applies to all employees of IMPLAN who take part in risk assessment and risk treatment.

Background:

A key element of IMPLAN’s information security program is a holistic and systematic approach to risk management. This policy defines the requirements and processes for IMPLAN to identify information security risks. The process consists of four parts: identification of IMPLAN’s assets, as well as the threats and vulnerabilities that apply; assessment of the likelihood and consequence (risk) of the threats and vulnerabilities being realized, identification of treatment for each unacceptable risk, and evaluation of the residual risk after treatment.

Policy:

Risk Assessment
1. The risk assessment process includes the identification of threats and vulnerabilities having to do with company assets.
2. The first step in the risk assessment is to identify all assets within the scope of the information security program; in other words, all assets which may affect the confidentiality, integrity, and/or availability of information in IMPLAN. Assets may include documents in paper or electronic form, applications, databases, information technology equipment, infrastructure, and external/outsourced services and processes. For each asset, an owner must be identified.
3. The next step is to identify all threats and vulnerabilities associated with each asset. Threats and vulnerabilities must be listed in a risk assessment table. Each asset may be associated with multiple threats, and each threat may be associated with multiple vulnerabilities. A sample risk assessment table is provided as part of the Risk Assessment Report Template (reference (a)).
4. For each risk, an owner must be identified. The risk owner and the asset owner may be the same individual.
5. Once risk owners are identified, they must assess:
6. The risk level is calculated by adding the consequence score and the likelihood score.

Description of Consequence Levels and Criteria:

Consequence Level	Consequence Score	Description
Low	0	Loss of confidentiality, integrity, or availability will not affect IMPLAN’s legal or contractual obligations, or reputation. No impact on Clients.
Medium	1	Loss of confidentiality, integrity, or availability will have low or moderate impact on IMPLAN’s legal or contractual obligations, or reputation. No impact on Clients.
High	2	Loss of confidentiality, integrity, or availability will have immediate and considerate impact on IMPLAN’s legal or contractual obligations, or reputation, or any impact on Clients.

Description of Likelihood Levels and Criteria:

Likelihood Level	Likelihood Score	Description
Low	0	Either existing security controls are strong and have so far provided an adequate level of protection, or the probability of the risk being realized is extremely low. No new incidents expected in the future.
Moderate	1	Either existing security controls are strong and have so far provided an adequate level of protection or the probability of the risk being realized is moderate. Some minor incidents may have occurred. New Incidents are possibly, but not highly likely
High	2	Either existing security controls are not in place or ineffective; there is a high probability of the risk being realized. Incidents have a high likelihood of occurring in the future.

Risk Acceptance Criteria
1. Risk values 0 through 2 are considered to be acceptable risks.
2. Risk values 3 and 4 are considered to be unacceptable risks. Unacceptable risks must be treated.
Risk Treatment
1. Risk treatment is implemented through the Risk Treatment Table. All risks from the Risk Assessment Table must be copied to the Risk Treatment Table for disposition, along with treatment options and residual risk. A sample Risk Treatment Table is provided in reference (a).
2. As part of this risk treatment process, the CEO and/or IMPLAN leadership may determine objectives for mitigating or treating risks. All unacceptable risks must be treated. For continuous improvement purposes, leadership may also opt to treat other risks for company assets, even if their risk score is deemed to be acceptable.
3. Treatment options for risks include the following options:
4. After selecting a treatment option, the risk owner should estimate the new consequence and likelihood values after the planned controls are implemented.
Regular Reviews of Risk Assessment and Risk Treatment
1. The Risk Assessment Table and Risk Treatment Table must be updated when newly identified risks are identified. At a minimum, this update and review shall be conducted once per year. It is highly recommended that the Risk Assessment and Risk Treatment Table be updated when significant changes occur to IMPLAN, technology, business objectives, or business environment.
Reporting
1. The results of risk assessment and risk treatment, and all subsequent reviews, shall be documented in a Risk Assessment Report.

Secure Software Development Lifecycle Policy

Reviewed: 9/26/2024

Updated: 9/26/2024

Purpose and Scope:

The purpose of this policy is to define requirements for establishing and maintaining baseline protection standards for company software, network devices, servers, and desktops.
This policy applies to all users performing software development, system administration, and management of these activities within IMPLAN. This typically includes employees and contractors, as well as any relevant external parties involved in these activities (hereinafter referred to as “users”). This policy must be made readily available to all users.
This policy also applies to enterprise-wide systems and applications developed by IMPLAN or on behalf of IMPLAN for production implementation.

Background:

The intent of this policy is to ensure a well-defined, secure and consistent process for managing the entire lifecycle of software and information systems, from initial requirements analysis until system decommission. The policy defines the procedure, roles, and responsibilities, for each stage of the software development lifecycle.
Within this policy, the software development lifecycle consists of requirements analysis, architecture and design, development, testing, deployment/implementation, operations/maintenance, and decommission. These processes may be followed in any form; in a waterfall model, it may be appropriate to follow the process linearly, while in an agile development model, the process can be repeated in an iterative fashion.

Policy:

IMPLAN’s Software Development Life Cycle (SDLC) includes the following phases:
1. Requirements Definition
  1. All requirements are written and tracked in our issue tracking system
  2. Requirements are prioritized based on customer value, customer impact, and effort and complexity required.
  3. Customer interviews/surveys are performed as applicable to ensure customer needs are met.
  4. Requirements are assigned to a sprint for implementation and testing, and sprints are bundled into Releases.
  5. Releases are scheduled to bundle a set of requirements. Releases are made no less than quarterly.
  6. Release dates are communicated 2 releases in advance with an earliest/latest methodology.
2. Implementation and testing
  1. Requirements are assigned to a development resource(s) for a particular sprint.
  2. Release candidates are fully tested with a test sprint prior to deployment.
  3. In parallel, our software test team completes the test plan for the requirements. This includes regression coverage, test case and scenario creation and validation, and functional testing.
  4. Refactoring bandwidth is assigned for each release to ensure scale, security and performance.
  5. All features are deployed to an internal test environment. Formal software testing as well as data quality control testing (by our economics team to ensure input and output data conforms to expected results) are performed in our test environment prior to deployment.
  6. All software is stored in a private cloud based software repository.
3. Releases
  1. Scheduled releases are deployed to our production environment during defined maintenance windows.
  2. Best commercial efforts are made for all non-critical software releases to be made during maintenance windows
  3. Releases are re-tested against both the formal test plan as well as for data and computational integrity by our economics team.
4. Continuous Improvement
  1. Retrospectives are performed after each sprint to identify opportunities to improve process and software quality
During all phases of the SDLC where a system is not in production, the system must not have live data sets that contain information identifying actual people or corporate entities. Information that would be considered sensitive must never be used outside of production environments.
The following activities must be completed and/or considered during the requirements definition phase:
1. Analyze business requirements.
2. Perform a risk assessment. More information on risk assessments is discussed in the Risk Assessment Policy.
3. Discuss aspects of security (e.g., confidentiality, integrity, availability) and how they might apply to this requirement.
4. Review requirements and IMPLAN’s policies, standards, procedures and guidelines.
5. Review future business goals.
6. Review current business and information technology operations.
7. Incorporate program management items, including:
  1. Analysis of current system users/customers.
  2. Understand customer-partner interface requirements (e.g., business-level, network).
  3. Discuss project timeframe.
8. Develop and prioritize security solution requirements.
9. Assess cost and budget constraints for security solutions, including development and operations.
10. Approve security requirements and budget.
11. Make “buy vs. build” decisions for security services based on the information above.
The following must be completed/considered during the implementation and testing phases
1. Architecture and design phase:
  1. Educate development teams on how to create a secure system.
  2. Develop and/or refine infrastructure security architecture.
  3. List technical and non-technical security controls.
  4. Perform architecture walkthrough.
  5. Create a system-level security design.
  6. Create high-level non-technical and integrated technical security designs.
  7. Perform a cost/benefit analysis for design components.
  8. Document the detailed technical security design.
  9. Perform a design review, which must include, at a minimum, technical reviews of application and infrastructure, as well as a review of high-level processes.
  10. Describe detailed security processes and procedures, including: segregation of duties and segregation of development, testing and production environments.
  11. Design initial end-user training and awareness programs.
  12. Design a general security test plan.
  13. Update IMPLAN’s policies, standards, and procedures, if appropriate.
  14. Assess and document how to mitigate residual application and infrastructure vulnerabilities.
  15. Design and establish separate development and test environments.
2. The following must be completed and/or considered during the development phase:
  1. Set up a secure development environment (e.g., servers, storage).
  2. Train infrastructure teams on installation and configuration of applicable software, if required.
  3. Develop code for application-level security components.
  4. Install, configure and integrate the test infrastructure.
  5. Set up security-related vulnerability tracking processes.
  6. Develop a detailed security test plan for current and future versions (i.e., regression testing).
  7. Conduct unit testing and integration testing.
3. The following must be completed and/or considered during the testing phase:
  1. Perform a code and configuration review through both static and dynamic analysis of code to identify vulnerabilities.
  2. Test configuration procedures.
  3. Perform system tests.
  4. Conduct performance and load tests with security controls enabled.
  5. Perform usability testing of application security controls.
  6. Conduct independent vulnerability assessments of the system, including the infrastructure and application.
The following must be completed and/or considered during the Release phase:
1. Conduct pilot deployment of the infrastructure, application and other relevant components.
2. Conduct transition between pilot and full-scale deployment.
3. Perform integrity checking on system files to ensure authenticity.
4. Deploy training and awareness programs to train administrative personnel and users in the system’s security functions.
5. Require participation of at least two developers in order to conduct full-scale deployment to the production environment.
The following must be completed and/or considered during the continuous improvement phase:
1. Several security tasks and activities must be routinely performed to operate and administer the system, including but not limited to:
  1. Administering users and access.
  2. Tuning performance.
  3. Performing backups according to requirements defined in the System Availability Policy
  4. Performing system maintenance (i.e., testing and applying security updates and patches).
  5. Conducting training and awareness.
  6. Conducting periodic system vulnerability assessments.
  7. Conducting annual risk assessments.
2. Operational systems must:
  1. Be reviewed to ensure that the security controls, both automated and manual, are functioning correctly and effectively.
  2. Have logs that are periodically reviewed to evaluate the security of the system and validate audit controls.
  3. Implement ongoing monitoring of systems and users to ensure detection of security violations and unauthorized changes.
  4. Validate the effectiveness of the implemented security controls through security training as required by the Incident Response Policy.
  5. Have a software application and/or hardware patching process that is performed regularly in order to eliminate software bug and security problems being introduced into IMPLAN’s technology environment. Patches and updates must be applied within ninety (90) days of release to provide for adequate testing and propagation of software updates. Emergency, critical, break-fix, and zero-day vulnerability patch releases must be applied as quickly as possible.
The following must be completed and/or considered during the decommission phase:
1. Conduct unit testing and integration testing on the system after component removal.
2. Conduct operational transition for component removal/replacement.
3. Determine data retention requirements for application software and systems data.
4. Document the detailed technical security design.
5. Update IMPLAN’s policies, standards and procedures, if appropriate.
6. Assess and document how to mitigate residual application and infrastructure vulnerabilities.

System Change Policy

Reviewed: 9/27/2024

Updated: 9/27/2024

Purpose and Scope:

This information security policy defines how changes to information systems are planned and implemented
This policy applies to the entire information security program at the organization (i.e. to all information and communications technology, as well as related documentation).
All employees, contractors, part-time and temporary workers, service providers, and those employed by others to perform work for the organization, or who have been granted to the organization’s information and communications technology, must comply with this policy.

Background:

This policy defines specific requirements to ensure that changes to systems and applications are properly planned, evaluated,approved, communicated, implemented, documented, and reviewed, thereby ensuring the greatest probability of success. Where changes are not successful, this document provides mechanisms for conducting post-implementation review such that future mistakes and errors can be prevented.

Policy:

Any changes to the security architecture or customer data handling of a system must be formally requested in writing to the organization’s Director of Infrastructure and Technology (DIT), and approved by the DIT and the Vice President of Product and Technology (VPPT).
All change requests must be documented.
All change requests must be prioritized in terms of benefits, urgency, effort required, and potential impacts to the organization’s operations.
All implemented changes must be communicated to relevant users.
Change management must be conducted according to the following procedure:
1. Planning: plan the change, including the implementation design, scheduling, and implementation of a communications plan, testing plan, and roll-back plan.
2. Evaluation: evaluate the change, including priority level of the service and risk that the proposed change introduces to the system; determine the change type and the specific step-by-step process to implement the change.
3. Review: review the change plan amongst the VPPT, DIT, Engineering Lead, and, if applicable, Business Unit Manager.
4. Approval: the VPPT must approve the change plan.
5. Communication: communicate the change to all users of the system.
6. Implementation: test change in non-production environment and implement the change.
7. Documentation: record the change and any post-implementation issues.
8. Post-change review: conduct a post-implementation review to determine how the change is impacting the organization, either positively or negatively. Discuss and document any lessons learned.

Vendor Management Policy

Reviewed: 9/27/2024

Updated: 9/27/2024

Purpose and Scope:

This policy defines the rules for relationships with IMPLAN’s Information Technology (IT) vendors and partners.
This policy applies to all IT vendors and partners who have the ability to impact the confidentiality, integrity, and availability of IMPLAN’s technology and sensitive information, or who are within the scope of IMPLAN’s information security program.
This policy applies to all employees and contractors that are responsible for the management and oversight of IT vendors and partners of IMPLAN.

Background:

The overall security of IMPLAN is highly dependent on the security of its contractual relationships with its IT suppliers and partners. This policy defines requirements for effective management and oversight of such suppliers and partners from an information security perspective. The policy prescribes minimum standards a vendor must meet from an information security standpoint, including security clauses, risk assessments, service level agreements, and incident management.

Policy:

IT vendors are prohibited from accessing IMPLAN’s information security assets until a contract containing security controls is agreed to and signed by the appropriate parties.
All IT vendors must comply with the security policies defined and derived from the Information Security Policy.
All security incidents by IT vendors or partners must be documented in accordance with IMPLAN’s Security Incident Response Policy and immediately forwarded to the Information Security Manager (ISM) as defined within the policy.
IMPLAN must adhere to the terms of all Service Level Agreements (SLAs) entered into with IT vendors. As terms are updated, and as new ones are entered into, IMPLAN must implement any changes or controls needed to ensure it remains in compliance.
Before entering into a contract and gaining access to IMPLAN’s information systems, IT vendors must undergo a risk assessment.
1. Security risks related to IT vendors and partners must be identified during the risk assessment process.
2. The risk assessment must identify risks related to information and communication technology, as well as risks related to IT vendor supply chains, to include sub-suppliers.
IT vendors and partners must ensure that organizational records are protected, safeguarded, and disposed of securely. IMPLAN strictly adheres to all applicable legal, regulatory and contractual requirements regarding the collection, processing, and transmission of sensitive data such as Personally-Identifiable Information (PII).
IMPLAN may choose to audit IT vendors and partners to ensure compliance with applicable security policies, as well as legal, regulatory and contractual obligations.

Workstation Policy

Reviewed: 9/27/2024

Updated: 9/27/2024

Purpose and Scope:

This policy defines best practices to reduce the risk of data loss/exposure through workstations.
This policy applies to all employees and contractors. Workstation is defined as the collection of all company-owned and personal devices containing company data.

Policy:

Workstation devices must meet the following criteria:
1. Operating system must be no more than one generation older than current
2. Device must be encrypted at rest
3. Device must be locked when not in use or when employee leaves the workstation
4. Workstations must be used for authorized business purposes only
5. Loss or destruction of devices should be reported immediately
6. Laptops and desktop devices should run the latest version of antivirus software that has been approved by IT
Desktop & laptop devices
1. Employees will be issued a desktop, laptop, or both by the company, based on their job duties. Contractors may be provided with IMPLAN equipment; otherwise, will provide their own laptops.
2. Desktops and laptops must operate on macOS or Windows.
Mobile devices
1. Mobile devices must be operated as defined in the Cloud Storage and BYOD Policy.
2. Mobile devices must operate on iOS or Android.
3. Company data may only be accessed on mobile devices using the following apps:.
  1. Slack
  2. Outlook or Mail
  3. Jira
Removable media
1. Removable media is permitted on approved devices as long as it does not conflict with other policies.

Table of Contents

Access Onboarding and Termination Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Purpose and Scope:

Background:

Policy:

Accessibility Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Policy:

Application Security Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Purpose and Scope:

Background:

Policy:

Appendix A: References

Authorized User Password Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Purpose and Scope:

Background:

Policy:

Availability Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Purpose and Scope:

Background:

Policy:

Business Continuity Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Purpose and Scope:

Background:

Policy:

Cloud Storage and BYOD Policy

Reviewed: 9/20/2024

Updated: 9/20/2024

Purpose and Scope:

Background:

Policy:

Code of Conduct Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

Policy:

Confidentiality Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

Background:

Policy:

Data Classification Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

Background:

Policy:

Appendix A: Handling of Classified Information

Data Retention Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

Background:

Policy:

Datacenter Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

Policy:

Disaster Recovery Policy

Reviewed: 9/23/2024

Updated: 9/23/2024

Purpose and Scope:

Background:

Policy:

Encryption Policy

Reviewed: 9/23/2024

Updated: 9/23/2024