Trust Center

Purpose and Scope

This Acceptable Use Policy defines standards for appropriate and secure use of raia’s hardware and electronic systems including storage media, communication tools and internet access. From time to time, raia may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations. This policy is guided by security requirements specific to raia including applicable laws and regulations.

This policy applies to all raia personnel acting on behalf of raia or accessing its applications, infrastructure, systems or data. All personnel are required to read, accept and follow all raia policies and plans.

General

Ownership

raia is the owner of all company-issued hardware and electronic systems including the data stored in them or transmitted from them.

User Responsibilities

Personnel should not make any discriminatory, disparaging, defamatory or harassing comments when discussing raia. Discussing raia includes the use of social media, blogging or otherwise engaging in any conduct to the detriment of raia.

Personal Use Systems

Personal use of raia electronic systems is permitted provided such use does not interfere with productivity, confidentiality or the business and is not in conflict with team member responsibilities outlined in any raia policy.

Compliance

For security and network maintenance purposes, raia may monitor and track system access and content of raia hardware, system(s) and information to reasonably ensure compliance with applicable laws, regulations and raia policies.

raia reserves the right to access and audit any devices, networks and systems to ensure compliance with any raia policy.

Communication Tools

Use of Email and Messaging Tools

Email (e.g., Google Workspace, MailGun, SendGrid) and other messaging tools (e.g., Slack, Google Voice, Twilio) are intended to be used as business tools to facilitate communications and the exchange of information needed by team members to perform their assigned duties.

Encryption

All messages and/or attachments that contain confidential information are required to be encrypted to protect the privacy of the information.

Responsibilities

Passwords should not be shared with another individual. They are intended for the authorized team member only.

Team members who transmit confidential information outside the organization should comply with applicable regulatory requirements, customer requirements, and raia policies regarding the disclosure of confidential information to third parties.

Communications may be monitored and tracked without consent or advanced notice to the team member.

Retention and disposal of electronic communications should be in accordance with all raia data protection and privacy policies.

Prohibited Uses of Communication Tools

• Dissemination of confidential or protected information (i.e., trade secrets, team member personal information or financial data, customer information, etc.), except for approved business purposes.
• Attempting to gain access to another team member’s account, without permission.
• Misrepresenting, obscuring, suppressing, or replacing a team member’s identity.
• Sending confidential information over an open network (the Internet) without proper encryption.
• Transmitting, retrieving, or storing any communications or materials of a defamatory, discriminatory, harassing, or obscene nature.
• Transmitting messages with derogatory or inflammatory remarks about an individual's race, age, disability, religion, national origin, physical attributes or sexual preference.

Devices

Use of Company Devices

The use of raia phones (static and mobile), laptops and other hardware is primarily for business use.

Use of Personal Devices (BYOD)

The use of a personal device for raia purposes should be limited to email and the raia messaging tool unless there is business justification and formal approval. Personnel must not save raia data to any personal device. Personnel are responsible for configuring their device to be in alignment with the device configuration settings specified in the next section of this policy. Personal phones are not in scope for this policy.

Mobile Device Management (MDM)

Mobile device management (MDM) is implemented to manage and enforce mobile device configuration and security policies. Mobile devices must be approved prior to granting access to resources. raia utilizes Secureframe Agent for device monitoring.

The MDM solution should ensure and/or manage the following:

• Encryption: User endpoint storage is encrypted at rest (e.g., FileVault for macOS or BitLocker for Windows).
• Security Updates: OS security updates are enforced and monitored.
• Malware Protection: Malware protection is enabled (e.g., XProtect for macOS, Windows Defender for Windows).
• Screensaver / Lockscreen: Screensavers / lockscreens are configured to activate after a maximum of 15 minutes.
• Logging: Logs are captured and stored to assist with security investigations.
• Password Policy: Required passwords must align with raia's Access Control and Termination Policy.
• Firewall: Local firewall is enabled to provide layered host protection unless it interferes with development activities.
• Remote Wipe (Optional): In the event of employee departure or theft, the mobile devices can be remotely wiped.

Employees and applicable contractors must report loss, theft, or other security incidents related to their company-provided mobile device in a timely manner.

Use of Removable Media

raia personnel must only use approved removable media on their work computers. Sensitive information must only be stored on removable media only when required in the performance of assigned duties and upon management's approval. When sensitive information is stored on removable media, it must be encrypted in accordance with the raia Encryption and Key Management Policy. Exceptions to this requirement may be granted by senior management.

Responsibilities

Personal use of raia devices are allowed only as set forth in the General section of this policy.

Personnel assigned a raia device are responsible for protecting the device from theft or damage.

If the issued device is lost or stolen, personnel responsible for the device must report the loss or theft to r@raiaai.com.

Devices that have not been approved by management should not be used to send or store any confidential information.

Social Media

Limited and occasional use of raia devices to access social media is acceptable, provided that it is done in a professional and responsible manner, does not otherwise violate raia policies, is not detrimental to the best interests of raia, and does not interfere with a team members regular work duties.

Networks and Internet Access

Responsibilities

Use of internet access is primarily for business use. Personal use is allowed only as set forth in this policy.

Access to the raia production network (e.g., Google Cloud) must be secure.

No confidential information shall be sent from to an individual or entity outside of raia using personal email accounts.

Personnel must use the production network and internet only for lawful purposes.

Encryption

raia users who are in travel status and use laptops to access the production network or company data should reasonably ensure such transmissions are encrypted and only access the network through authorized means. During travel, access to the internet should only be made via secure wireless networks.

Explicit Content

Users using raia devices who discover they have connected with a web site that contains sexually explicit, racist, violent, or other potentially offensive material must immediately leave the site and report such use to r@raiaai.com.

Prohibited Uses

You agree not to use personal email accounts for, but not limited to:

• Dissemination of confidential information.
• Attempting to gain access to another Internet account, without permission.
• Sending confidential information over the Internet without proper encryption.

You agree not to use network and internet access to:

• Violate any applicable federal, state, local, or international law or regulation (including, without limitation, any laws regarding the export of data or software to and from the US or other countries).
• Access data, a server or an account for any purpose other than conducting raia business, even if you have authorized access.
• Make statements about warranty, expressly or implied, unless it is a part of normal job duties.
• Make fraudulent offers of products, items, or services originating from any raia account.
• For the purpose of exploiting, harming, or attempting to exploit or harm, minors in any way by exposing them to inappropriate content, asking for personally identifiable information, or otherwise.
• Send, knowingly receive, upload, download, use, or re-use any material which violates the rights of any individual or entity established in any jurisdiction.
• Transmit, or procure the sending of, any advertising or promotional material, including any "junk mail," "chain letter," "spam," or any other similar solicitation.
• Impersonate or attempt to impersonate raia, an employee, contractor, another user, or any other person or entity (including, without limitation, by using e-mail addresses or screen names associated with any of the foregoing).
• Engage in any other conduct that restricts or inhibits anyone's use of the network, or which, as determined by us, may harm raia or users of the network or expose them to liability.
• Disable, overburden, damage, or impair the network or interfere with any other party's use of the network, including their ability to engage in real time activities through the network.
• Use any robot, spider, or other automatic device, process, or means to access the network for any purpose, including monitoring or copying any network traffic or resources available on the network.
• Use any manual process to monitor or copy any network traffic or resources available on the network or for any other unauthorized purpose without raia's prior written consent.
• Use any device, software, or routine that interferes with the proper working of the network.
• Introduce any viruses, honeypots, trojan horses, worms, logic bombs, or other software or material which is malicious or technologically harmful.
• Attempt to gain unauthorized access to, interfere with, damage, or disrupt any parts of the network or any server, computer, database, or other resource or element connected to the network.
• Violate, attempt to violate, or knowingly facilitate the violation of the security or integrity of the network.
• Use of organization-provided identifiers (e.g., email addresses) and authentication secrets (e.g., passwords) for creating accounts on external sites/applications.

Content Standards

You agree not to send, knowingly receive, upload, download, use, or re-use any material which:

• Contains any material that is defamatory, obscene, indecent, abusive, offensive, harassing, violent, hateful, inflammatory, or otherwise objectionable.
• Promotes sexually explicit or pornographic material, violence, or discrimination based on race, sex, religion, nationality, disability, sexual orientation, or age.
• Infringes any patent, trademark, trade secret, copyright, or other intellectual property or other rights of any other person.
• Violates the legal rights (including the rights of publicity and privacy) of others or contains any material that could give rise to any civil or criminal liability under applicable laws or regulations.
• Is likely to deceive any person.
• Promotes any illegal activity, or advocates, promotes, or assists any unlawful act.
• Causes annoyance, inconvenience, or needless anxiety or is likely to upset, embarrass, alarm any other person.
• Impersonates any person, or misrepresents your identity or affiliation with any person or organization.
• Gives the impression that material emanates from or is endorsed by raia or any other person or entity, if this is not the case.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any personnel who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

raia

Access Control and Termination Policy

Purpose and Scope

This Access Control and Termination Policy defines requirements for access and removal of access to raia data, systems, facilities, and networks. From time to time, raia may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations. This policy is guided by security requirements specific to raia including applicable laws and regulations.

This policy applies to all raia assets or approved devices utilized by personnel acting on behalf of raia or accessing its applications, infrastructure, systems or data. All personnel are required to read, accept, and follow all raia policies and plans.

Access Control Requirements

Principle of Least Privilege

raia adheres to the principle of least privilege, specifying that users of raia systems will be given minimum access to data and systems based on job function, business requirements, or need-to-know for that specific user. Access to systems should be provisioned via a deny-all methodology - users should only gain access to a system upon receiving formal independent approval.

Administrative access to production servers and databases is restricted based on the principle of least privilege for personnel who have a job function and business need for such access. Access to systems and applications must be controlled by a secure log-on process to prove the identity of the user.

Unique Accounts

Users of raia systems and applications will be provided with unique credentials (IDs, keys, etc.) that can be used to trace activities to the individual responsible for that account. Shared user accounts shall only be utilized in circumstances where there is a clear business benefit and when user functions do not need to be traced. Shared account password should only be stored in a raia approved password manager.

Password Security

Unique accounts and passwords are required for all users. Passwords must be kept confidential and not shared with multiple users. Where possible, all user and system account passwords must be a minimum of eight characters and complex. All accounts must use unique passwords not used elsewhere.

Rotation Requirements

If an account is suspected to be compromised, the password should be reset and the security team should be immediately notified.

Storing Passwords

Passwords must only be stored using a raia approved password manager. raia does not hard code passwords or embed credentials in static code.

Multi-Factor Authentication

When available, multi-factor authentication should be used. Multi-factor authentication must be used for access to company email, version control tool and cloud infrastructure.

Onboarding Procedures

In order to onboard new personnel, the following steps should be taken and documented:

• Any raia devices provided to the new hire must be inventoried in accordance with raia policy
• A new hire email or ticket must be sent to the appropriate team to inform them of new personnel
• IT/Engineering and the new personnel’s manager must document a checklist of accounts and permission levels needed for that hire
• The applicable team must set up each user with the appropriate access, both logical and physical
• All of the onboarding processes must be appropriately documented via ticketing or other document management tools

Offboarding Procedures

In order to offboard an employee or contractor, the following steps must be taken:

• An offboarding email or ticket must be sent to IT/Engineering when personnel has been terminated or resigned informing IT/Engineering of the team members’ last day
• IT/Engineering must review and perform action against the appropriate revocation checklist to revoke access to raia systems, applications, and physical access points (as applicable) within 24 hours of the last day with the company or sooner if necessary
• Any raia devices provided must be collected and accounted for in accordance with raia policy
• All of the offboarding processes must be appropriately documented via raia ticketing or other document management tools

Changes to Access

Requests for changes to access level(s), such as in the cases of a change in job duties or an emergency requiring elevated permissions, must be documented and approved by the appropriate manager.

A documented request must be sent to the appropriate department when an employee or contractor role changes to evaluate whether access privileges should be changed. When accounts are no longer required, user access rights must be reviewed and reallocated as necessary prior to changes being made.

Such changes must be tracked using the raia ticketing or other document management tools.

Quarterly Access Reviews

A team manager must review, audit, and document user accounts and associated privileges of at least high-risk and critical systems at least quarterly to ensure that access is restricted appropriately.

Exceptions

raia business needs, local situations, laws, and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any personnel who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

raia

Business Continuity and Disaster Recovery Plan

Purpose and Scope

This Business Continuity and Disaster Recovery Plan guides raia in the event of a significant business disaster or other disruption to normal service. raia must respond to business disasters and disruption by safeguarding employees’ lives and company assets, making a financial and operational assessment, securing data, and quickly recovering operations.

This plan applies to all raia assets utilized by employees and contractors acting on behalf of raia or accessing its applications, infrastructure, systems, or data. All employees and contractors are required to read, accept, and follow all raia policies and plans.

Scope for Mission Critical Services

Mission critical services and systems are those required for the functioning of the raia product(s). Mission Critical services and systems include critical production systems required for immediate recovery, services affecting the engineering team’s ability to support production operations and product development, and the ability to support raia customers.

All essential data is typically stored remotely using commercial cloud providers with proper backup and redundancy processes in place. This approach is subject to change and designed to minimize any disruption from physical incidents or disasters.

System Outages

Planned Outage

From time to time, raia may distribute a service update to all affected users prior to planned downtime.

Unplanned Outage

All unplanned outages should be treated as an incident; r@raiaai.com and the executive team should be immediately emailed and notified of any unplanned outage.

Expectations

Alternate Physical Location(s) of Employees

In the event of an internal disaster that affects a raia office location, all team members will be moved from such affected offices to each member’s respective home or an alternate location to work remotely.

Reliance on Third-Party Services

raia utilizes and relies on mission critical third-party cloud services. In the event of a significant business disaster, raia will quickly work to establish alternative arrangements if a mission critical vendor can no longer provide the needed services or goods.

Mission critical third-party vendors include:

• Google Cloud
• Google Workspace
• GitHub
• OpenAI
• Stripe
• n8n

This plan depends on the likelihood that:

• Remote work can continue to take place in the event of a disaster; and
• Mission critical vendor services, and essential raia services, systems, and data can still be made available or alternative solutions can be implemented (including backups and services provided by such third-party vendors)

Priorities

In the event of a disaster affecting raia essential systems or its team members, Richard Swier will oversee and respond in accordance with this Plan and will initiate specific actions for recovery.

The priorities during a business disaster are to:

• Secure the safety of team members and visitors;
• Mitigate threats or limit the damage that threats can cause to raia, its team, and its customers; and
• Ensure that essential business functions can continue or determine what is required to restart essential business functions

Backup and Retention

All vital data that would be affected by disruption are maintained and controlled by the data’s applicable teams.

In the event of a facility disruption, critical records located in such a facility may be destroyed or inaccessible. The number of critical records, which would have to be reconstructed, will depend on when the last transfer of critical records to the cloud storage location occurred.

Backup Requirements

• Database backups must be performed daily
• Backups must be retained for at least 30 days
• The maximum allowable retention period for a database backup should be determined based on regulatory and contractual requirements
• Backups are periodically tested to ensure that backups are sufficient and reliable in accordance with this plan
• Backup systems and media protect the availability of stored data

Alternate Communication

The organization may communicate using telephone, video conferencing tools, messaging tools, email, physical mail, and in person.

In the event of a significant business disaster, an assessment will be conducted to determine which means of communication are still available. These means of communication will then be utilized to communicate with personnel, customers, partners and other third-parties.

Testing

Testing the plan is critical to ensuring the plan is effective and practical. Any gaps in the plan that are discovered during the testing phase will be addressed by Richard Swier and any designee. All tests must be thoroughly documented.

Testing of this plan may be performed using the following methods noted in the subsections below.

Walkthroughs

Team members must walk through the steps documented in this plan to confirm effectiveness, identify gaps, bottlenecks or other weaknesses. This walkthrough provides the opportunity to review the plan with all relevant stakeholders and familiarize them with procedures, equipment, offsite facilities, and recovery efforts in preparation of a business disaster or disruption.

Table Top Exercises

Hardware, software, personnel, communications, procedures, supplies and forms, documentation, transportation, utilities, and alternate site processing should be thoroughly tested in a simulation test.

Personnel involved with business continuity must utilize validated checklists to provide a reasonable level of assurance for many disaster scenarios. These personnel must analyze the output of the previous tests carefully before the proposed simulation to ensure the lessons learned during the previous phases of the cycle have been applied.

Business Continuity and Disaster Recovery Stages

This Plan divides recovery into three stages: Disaster, Response, and Recovery.

Declaring a disaster is the responsibility of senior management. Since it is almost impossible to predict when and how a disaster might occur, raia and its team members must be prepared to monitor and signal a disaster to management from:

• First hand observation
• Security applications
• Network monitoring and logging tools
• Environmental and security alarms
• Team members
• Customers
• Partners
• Vendors
• Media

Disaster Stage

If a disaster has been declared, this Plan and any related responses would go into effect.

The disaster stage may include the following processes:

• Senior management declares the disaster, and
• Notifies management and appropriate team members to create the appropriate Disaster Recovery Team (DRT) consisting of Richard Swier (lead), Thomas Hall, and Lee Dickson,
• DRT initiates internal and external communication lines, and communicates to the following parties as appropriate:
• General Counsel
• Authorities
• Personnel
• Customers
• Vendors, third-parties, and other applicable stakeholders
• DRT determines appropriate emergency response measures

Response Stage

In this phase, the team determines what team members, facilities and customer deployments are affected by the disaster scenario and in what way they are affected by performing an impact assessment.

This stage continues until an alternate facility location and/or essential business and production functions are established and services restored. If non-essential functions are affected, essential functions may be prioritized during a disaster event.

The response stage may include the following processes:

• Execution of a business impact assessment,
• Relocation to an alternative facility or establish work from home requirements,
• Verification and/or backing up of affected data and systems, and
• Restoration of essential raia services

Recovery Stage

Recovery begins with the activities necessary to return to business as usual including re-establishing the primary facility. For engineering, this stage begins with the restoration of raia services in an available commercial cloud provider’s region. Recovery time objectives (RTOs) and recovery point objectives (RPOs) are to be defined when relevant for applicable systems.

• Recovery time objective(s) (RTO): 4 hours
• Recovery point objective(s) (RPO): 1 hour

Key Learning Stage

As soon as possible, raia senior management must meet with the DRT and other stakeholders for a post-mortem review to better understand the disaster event that took place and how it and others may be prevented in the future.

The retrospective must be documented and key learnings from the retrospective should be presented to all appropriate team members in a timely manner.

Lessons learned during the disaster must be captured within the post-mortem review and incorporated as updates into existing documentation.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

This Business Continuity and Disaster Recovery Plan is reviewed and tested at least annually. Ensuring that the plan reflects ongoing changes to resources is crucial. This task includes updating the plan, testing the updates with walkthroughs, tabletop exercises, and training necessary personnel. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually.

This development, maintenance, and testing of this plan are approved by Richard Swier.

This plan was last updated on May 7, 2026.

raia

Purpose and Scope

This Change Management Policy defines how changes to applications, systems, services, and infrastructure are planned and implemented. The goal of change management is to increase awareness and understanding of proposed changes across raia and ensure that all changes are made in a thoughtful way that minimize negative impact to services and customers.

From time to time, raia may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations. This policy is guided by security requirements specific to raia including applicable laws and regulations.

This policy applies to all raia assets and personnel acting on behalf of raia or accessing its applications, infrastructure, systems or data. All personnel are required to read, accept and follow all raia policies and plans.

Change Management

All code change requests and critical infrastructure or network-related change requests must be documented end-to-end via raia's change management and ticketing tools (e.g., Confluence, GitHub).

Change management should be conducted according to the following procedure:

(1) Product Roadmap

The raia product management team evaluates which change requests and features will be implemented based on their alignment with the business plan and the overall level of effort required. All change requests should be prioritized in terms of benefits, urgency, effort required, security impacts, and other potential impacts on the organization’s operations.

A ticket should be created to track a change request at the onset. If the change is part of an existing ticket the original ticket may be used and modified appropriately.

(2) Planning and Evaluation

Planning and evaluation must include design, scheduling, and implementation of a communications plan, testing plan, and roll-back plan. During planning, wire-frames, mockups, and functional requirements may be created and reviewed among the applicable team members. The team may set priority levels of the service and may determine any risk that the proposed change introduces to the system. It is during this phase that the scope and impact of the change will be determined.

(3) Build, Test, and Document

During building, raia sprints may be defined and the overall software design and development occurs.

UI/UX and other optimizations should be performed during this phase to enhance the performance and security of the change across all platforms.

The changes must be tested in a non-production environment before release to production. Test setups and scenarios are built for operational, performance, and security testing. Test scripts and suites should be developed, used, and updated as changes occur.

Documentation must be updated during this phase, such as release notes, help articles, and blog posts. Existing documentation is updated to ensure that team members and customers have the most up-to-date and accurate information related to the changes performed. Customer-facing documentation should be provided to raia customers as applicable.

(4) Code Review

raia uses code reviews to maintain the quality of raia code and products. Code reviewers should look at:

• Design: Is the code well-designed and appropriate for your system?
• Functionality: Does the code behave as intended by the plan? Is the way the code behaves good for its users?
• Complexity: Could the code be made simpler? Would another developer be able to easily understand and use this code when they come across it in the future?
• Tests: Does the code have correct and well-designed automated tests?
• Security: Are there any security risks in the code as identified by the latest OWASP Top 10?
• Naming: Are there clear names for variables, classes, methods, etc.?
• Comments: Are the comments clear and useful?
• Style: Does the code follow raia style guides?
• Documentation: Was the relevant documentation updated or created?

Secure Coding

Secure coding practices are incorporated into the development lifecycle and security architecture of raia. Engineers at raia are responsible for defining security requirements initially and throughout all phases of the software development life cycle and then evaluating for compliance with those requirements.

(5) Approval and Implementation

Once the new release is ready for deployment and the appropriate documentation is in place, the new release must be approved and reviewed by the appropriate product owner prior to being pushed to the production environment.

The ability to push changes to production at raia must be restricted to a limited set of authorized team members, and the engineer responsible for coding the change should not also be responsible for pushing the change to production, unless there is prior approval of the exception by management.

(6) Communication

Implemented changes should be communicated to all applicable team members and externally as appropriate.

(7) Post-Change Review

raia continuously measures the success of new releases and identifies areas that can be enhanced further in the future.

The appropriate team must conduct a post-implementation review to determine how the change is impacting raia and raia's customers, either positively or negatively. Discuss and document any lessons learned with product management and other appropriate team members.

raia must utilize version control tools (e.g., GitHub) that allow for efficient rollbacks of commits from production if any issues arise during the post-change review.

Hotfixes / Critical Issues / Emergencies

The following are potential emergencies that may require a hotfix:

• A customer is completely out of service
• There is severe degradation of service needing immediate action
• A system/application/component is inoperable and the failure causes a significant negative impact
• A response to a natural disaster
• A response to an emergency business need
• A critical vulnerability or security issue is identified

If a hotfix is required, the applicable manager should be immediately notified.

The notification should include at a minimum the following information:

• Will the change cause an interruption in service?
• What additional customers will be affected (in the event a change is needed to fix an outage) and who needs to be notified?
• What is the possible workaround until the problem is resolved?
• What is the approximate length of the outage?
• Notification of resolution
• Submission of a ticket to accurately describe the outage

Emergencies after normal business hours, on the weekend, or on holidays, must follow an appropriate communication and resolution process. A ticket must be generated and team members may need to notify affected customers, as determined by management. Emergency changes must be revisited to ensure no additional security issues were introduced into the product, service, or supporting infrastructure. A completed ticket should be submitted through the regular reporting process promptly following when the change was made.

Management must review all emergency submissions to ensure the change met the criteria for an “emergency change” and to prevent the process from becoming normal practice to circumvent the Change Management Policy. Any questions will be directed to the individual(s) who approved the change.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

Purpose and Scope

This Code of Conduct outlines raia's expectations measured against the highest possible standards of ethical business conduct. Committing to the highest standards helps raia hire great people, build great products, and attract loyal customers.

From time to time, raia may update this Code of Conduct. This policy is guided by requirements specific to raia including applicable laws and regulations.

We expect all raia personnel to review, understand, and abide by this Code of Conduct in all matters related to raia.

Respect in the Workplace

All personnel must respect their colleagues. raia will not allow any kind of discriminatory behavior, harassment, or victimization.

raia prohibits retaliation against any personnel who report or participate in an investigation of a possible violation of raia's Code of Conduct, policies, or the law. If you believe you are being retaliated against, please contact Richard Swier, another senior manager, or anonymously at r@raiaai.com.

Personnel must use company assets as outline in the Acceptable Use Policy. This includes safe handling of trademarks, copyright, and other property (information, reports, etc.).

Safe Workplace

raia is committed to a violence-free work environment, and we will not tolerate any level of violence or the threat of violence in the workplace. Under no circumstances should anyone bring any type of weapon to work including guns, explosives, or knives. If you become aware of a violation of this policy, you should report it to a member of management immediately. In the case of potential physical violence, contact the authorities immediately.

Workplace Visitors

Workplace safety is very important to raia. As raia visitors access workplace premises, raia should ensure that visitors are not a threat to the workplace and are not exposed to danger.

Equal Opportunity Employment

raia is an equal opportunity employer. raia thrives on diversity and are committed to creating an inclusive environment for all personnel.

Professionalism

All personnel must show integrity and professionalism in the workplace.

Job Duties and Authority

All personnel should fulfill their job duties with integrity and respect toward customers, stakeholders and the community. Supervisors and managers must not abuse their authority.

We encourage mentorship throughout raia.

Communication and Collaboration

Personnel should be responsive and open for communication with their colleagues, supervisors, and team members. Personnel should be friendly and collaborative and not disrupt the workplace or hinder their colleagues' work.

Benefits

raia expects employees to not abuse their employment benefits. Please reach out to Human Resources for questions pertaining to company benefits.

Compliance with Law

Personnel must comply with all applicable laws including environmental, safety and fair dealing laws. raia expects everyone to be ethical and responsible during raia business dealings.

Conflict of Interest

Conflicts of interest occur when an employee, contractor, or job applicant's personal interests may not align with company needs or interests. We expect you to avoid any personal, financial, or other interests that might hinder your capability or willingness to perform your job duties. If you believe that a conflict may occur, please contact your manager immediately.

Types of conflicts of interest may include:

• Personal investments
• Outside employment, advisory roles, board seats, and starting your own business
• Business opportunities found through work
• Inventions
• Accepting gifts, entertainment, and other business courtesies

Internet and Social Media

Personnel should never share any intellectual property or the status of any of their assignments on social media.

When representing the company, personnel should always be respectful and avoid speaking in specifics about their work. Personnel should never post discriminatory, offensive, or other illegal language on social media.

Exceptions

raia business needs, local situations, laws, and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee's or contractor's course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

raia

Purpose and Scope

This Configuration and Asset Management Policy provides procedures supporting effective organizational asset management, specifically focused on electronic devices within the organization and baseline configurations for raia assets and systems.

From time to time, raia may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations. This policy is guided by security requirements specific to raia including applicable laws and regulations.

This policy applies to all raia assets utilized by personnel acting on behalf of raia or accessing its applications, infrastructure, systems or data. All personnel are required to read, accept and follow all raia policies and plans.

Configuration Standards

Production systems handling confidential data must have documented baseline configurations, when available. raia management is responsible for following documented standard configurations for all applicable assets including third-party cloud products and employee devices. Configuration standards should be available for reference by applicable personnel.

raia must continuously harden its systems via Secureframe compliance and security checks as well as Center for Internet Security (CIS) benchmarks and best practices. The compliance checks monitor system security parameters and safeguards.

raia must regularly patch and keep all applicable systems up to date.

All vendor supplied default configurations, including but not limited to passwords, user accounts, and administrative accounts, should be changed before any systems or devices are implemented.

Each applicable asset and system in the raia environment should be hardened to the minimum standards defined by raia management.

Hardening standards should be in line with industry standards and provide sufficient logical and physical security for the asset(s) being configured.

Minimum Device Configuration Settings

raia devices should be configured to these settings where possible:

• Encryption: User endpoint storage is encrypted at rest (e.g. FileVault for MacOS or Bitlocker for Windows)
• Security Updates: OS security updates are enforced and monitored
• Malware Protection: Malware protection is enabled (e.g XProtect for MacOS, Defender for Windows, or ClamAV for Linux)
• Screensaver / Lockscreen: Screensavers / lockscreens are configured to activate after a maximum of 15 minutes
• Logging: Logs are captured and stored to assist with security investigations
• Password Policy: Required passwords must align with raia's Access Control and Termination Policy
• Firewall: Local firewall is enabled to provide layered host protection unless it interferes with development activities
• Remote Wipe (Optional): In the event of employee departure or theft, the mobile devices can be remotely wiped

Non-Standard Configuration

If an asset must use a non-standardized configuration, approval of the use must be provided by raia management and such approval and request must be documented.

Asset Management

raia inventories and tracks all assets that are used to process, store, transmit, or otherwise impact the confidentiality, integrity, or availability of sensitive information. The asset inventory will include all systems connected to the network and network devices themselves. Examples of items to be inventoried are servers, datastores, network devices, applications, and workstations.

Lost Asset

If an asset is known to be lost or stolen, please report it immediately to r@raiaai.com.

Acquisition of New Assets

Business considerations must be reviewed, documented, and addressed prior to the acquisition of any new assets. raia management must approve any new assets that may be used to access raia data, systems, network, or applications. Reference the Data Classification Policy for more information.

Data as an Asset

Sensitive data is also considered an asset and should be tracked accordingly. Sensitive data must be stored in accordance with all security policies and the location of all covered data regardless of classification or encryption status must be maintained.

Asset Management Procedures

raia must maintain an inventory of servers, desktops, laptops, and other devices used to store, create, modify, delete, or transmit confidential information.

All assets should be mapped to the device’s serial number or another identifier.

Any asset no longer in use or deemed no longer usable will be removed from the inventory.

raia must perform periodic asset management system checks for various classes of asset records.

Any raia devices issued to personnel must be returned upon termination or resignation.

Asset Inventory Audit

Richard Swier or a designee will be held accountable for the accuracy of the inventory and must perform a documented review of the asset list at least annually.

Physical Media Transfer

Any media or device containing sensitive data must be shipped by a tracked carrier with a recipient signature required. For encrypted data, the encryption key should only be released after the package has arrived and been signed for. Media containing data will be protected against unauthorized access, misuse or corruption during transportation.

Legal advice should be sought to ensure compliance before media containing encrypted information or cryptographic controls are moved across jurisdictional borders.

Asset Disposal

When disposing of any asset, sensitive data must be removed prior to disposal. Any physical media storing confidential or personally identifiable information that is not being repurposed must be destroyed prior to disposal. Sanitization should occur in accordance with the NIST Guidelines for Media Sanitization (NIST S.P. 800-88 Rev. 1).

raia's third-party providers are responsible for physical protections and disposal of all assets under their control such as databases and servers.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

Purpose and Scope

This Data Classification Policy provides the basis for protecting the confidentiality of data at raia by establishing a data classification system. From time to time, raia may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations. This policy is guided by security requirements specific to raia including applicable laws and regulations.

This policy applies to all raia data assets utilized by personnel acting on behalf of raia or accessing its applications, infrastructure, systems or data. All personnel are required to read, accept and follow all raia policies and plans.

Classification Management

All raia data should be classified into one of the following four classifications:

• Restricted Data,
• Confidential Data,
• Internal Data, and
• Public Data.

All data that is not explicitly classified should be treated as confidential data and a classification should be determined and documented.

The examples below are not exhaustive. Data owners and senior management are responsible for assigning the types of ways certain data can be used as well as assigning the appropriate classification to raia data.

If you are unable to determine the appropriate data owner or a classification for the data or believe certain data should be reclassified, please contact r@raiaai.com.

Changes to the classification of data must be approved by senior management.

Classification Levels

Public Data

Public data is information that may be disclosed to any person regardless of their affiliation with raia. The Public classification is not limited to data that is of public interest or intended to be distributed to the public; the classification applies to data that does not require any level of protection from disclosure. While it may be necessary to protect original (source) documents from unauthorized modification, Public data may be shared with a broad audience both within and outside raia and no steps need be taken to prevent its distribution. Public data can be retained for an indefinite period of time.

Examples of Public data include:

• published press releases;
• published documentation,
• published blog posts,
• anything on the raia public website, and
• anything on raia social media profiles

Internal Data

Internal data is information that is potentially sensitive and is not intended to be shared with the public. Internal data should be classified as such when the unauthorized disclosure, alteration, or destruction of that data would result in moderate risk to raia, its customers, or its partners. Internal data generally should not be disclosed outside of raia without the permission of the data owner. It is the responsibility of the data owner to designate information as Internal where appropriate. If you have questions about whether information is Internal or how to treat Internal data, you should talk to your manager or send an email to r@raiaai.com.

Examples of Internal data include:

• unpublished raia memos,
• unpublished marketing materials,
• non-public raia customer and partner names, and
• procedural documentation that should remain private

Confidential Data

Confidential data is information that, if made available to unauthorized parties, may adversely affect individuals or raia. This classification also includes data that raia may be required to keep confidential, either by law or under a confidentiality agreement with a third party, such as a vendor. This information should be protected against unauthorized disclosure or modification. Confidential data should be used only when necessary for business purposes and should be protected both when it is in use and when it is being stored or transported. Confidential data should be retained for only as long as it is needed to conduct internal/external business operations. Customer deletion requests and contractual deletion obligations should be the main source of authority for storing/deleting Confidential data.

Any unauthorized disclosure or loss of Confidential data must be reported to r@raiaai.com.

Examples of Confidential data include:

• individual employment information, including salary, benefits and performance evaluations for current, former, and prospective employees,
• legal documents,
• customer data,
• contractual agreements,
• compliance reports such as SOC 2,
• data that is subject to an NDA or other confidentiality clause, and
• information shared by partners or investors

Restricted Data

Restricted data includes any information that raia has a legal or regulatory obligation to safeguard in the most stringent manner. Data should be classified as Restricted when the unauthorized disclosure, alteration or destruction of that data could cause a significant level of risk to raia, its customers, or its partners. The highest level of security controls should be applied to Restricted data.

Examples of Restricted data include:

• raia codebase,
• intellectual property,
• passwords, private keys and other credentials,
• bank information,
• tax ids,
• information related to pending litigation or investigations,
• data required to be protected by regulatory obligations, and
• additional employment information such as background checks, health and medical information, social security numbers

Restricted data should be used only when no alternative exists and must be carefully protected. Regulatory data retention requirements should be the main source of authority for storing/deleting restricted data, as applicable, unless stricter organizational requirements have been enacted. Any unauthorized disclosure, unauthorized modification, or loss of Restricted data must be immediately reported to your manager and r@raiaai.com.

Data Handling and Labeling

All personnel accessing classified information must follow the rules listed above. Each incident related to handling classified information must be reported in accordance with the Security Incident Response Plan.

All types and forms (e.g. digital, physical) of data should be clearly labeled, denoting respective classification tiers. As mentioned above, all data not explicitly classified must be treated as if it were confidential data. Classification tiers with labels are listed below:

• Public Data -> "FOR PUBLIC USE"
• Internal Data -> "CLASSIFICATION: INTERNAL"
• Confidential Data -> "CLASSIFICATION: CONFIDENTIAL"
• Restricted Data -> "CLASSIFICATION: RESTRICTED"

All physical (e.g. paper, posters, etc.) and digital (e.g. Word/Google Docs, Excel/Google Sheets, PowerPoint/Google Slides) media should have a footnote clearly stating the proper classification level at the bottom of each page/sheet/slide.

Data Storage

Personnel should be mindful of where to store data based on the degree of classification. Where possible, personnel should observe the principle of least privilege, or sharing only what absolutely needs to be known. For example, there is no need to share restricted data to persons who do not have the need to know. Personnel should be especially mindful when sharing data to external users outside of the company.

Data Deletion

The method for secure erasure and destruction of media is prescribed in the Configuration and Asset Management Policy and Data Retention and Disposal Policy.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

Purpose and Scope

The Data Retention and Disposal Policy - HIPAA Addendum identifies the requirements for data retention and sanitization pertaining to protected health information (PHI) and the implications for systems, infrastructure, and security mechanisms supporting and protecting PHI.

This addendum applies to all raia assets, which store, process, or transmit PHI, utilized by personnel acting on behalf of raia or accessing its applications, infrastructure, systems, or PHI data. All personnel are required to read, accept, and follow all raia policies and plans.

HIPAA Data Retention Requirements

All raia documents required by HIPAA to be retained including security policies, plans, and audit-related evidence must be retained for a minimum of six years from the longer of when the document was created, or from when it was last in effect. The full list of required documents to be maintained is as follows:

• The Company’s HIPAA Security Policies and Procedures Manual;
• The Company’s HIPAA Privacy Security Policies and Procedures Manual;
• Records of HIPAA training;
• Sanctions applied to workforce members who violate the raia’s HIPAA policies and procedures;
• Business Associate Agreements and lists of Covered Entities and Subcontractors;
• Complaints and resolutions;
• Records regarding workforce member access to PHI;
• Records and incident/breach documentation regarding breaches of unsecured PHI;
• Security risk analyses;
• Regulatory compliance correspondence and assessment reports;
• Physical security maintenance records;
• Information systems activity reviews, decisions made, and investigations conducted;
• Contingency plans in effect during the retention period;
• Contingency plan tests; and
• Records of the movements of hardware and electronic media used to store ePHI, including the receipt of any new hardware or electronic media storing ePHI. This record should contain, at a minimum, the name of the person responsible for the item, the location of the item, and any movement of the item.

The following raia technical data and audit-related evidence should be retained for a minimum of six years as strongly encouraged by HIPAA, permitting exceptions due to costs and logistical challenges:

• Forensic data that could be used to analyze PHI-related incidents
• Audit log records pertaining to access of ePHI

Events that should be monitored and retained include:

• Successful Logins
• Failed Login Attempts
• File Accessed
• Security Incidents
• Port Scans
• Backups records of ePHI

HIPAA Data Sanitization Requirements

raia will ensure the following data sanitation practices are adhered to:

• raia will ensure proper sanitation of all Electronic Media containing PHI before it is transferred from the custody of its current custodian. The proper sanitization method depends on the type of media and the intended disposition of the media.
• raia will not use ‘clearing data’ as a method for sanitizing media containing PHI. Clearing data (such as formatting or deleting information) removes information from storage media so that the information is unreadable. However, special utility software or techniques can be used to recover the cleared data.
• raia will use the following method for sanitizing Electronic Media containing PHI: Overwriting disk drives, Low-Level formatting and “Zeroing out the drive.” CDs are shredded and destroyed.
• raia will require vendors repairing or recovering data from any hard drive containing PHI to sign Business Associate Agreements. Once PHI is recovered or the hard drive is repaired, the original hard drive must be returned to the owner so that the owner can properly dispose of the hard drive.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

This plan will be reviewed and tested on an annual basis. Ensuring that the plan reflects ongoing changes to resources is crucial. This task includes updating the plan and revising this document to reflect updates; testing the updates; and training personnel. Test results will be documented and signed off by raia management. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is tested, maintained and enforced by Richard Swier.

This document was last updated on May 7, 2026.

Purpose and Scope

This Data Retention and Disposal Policy addresses how a customer's data is retained and disposed of and to ensure this is carried out in a consistent manner. From time to time, raia may update this policy. This policy is guided by security requirements specific to raia including compliance with applicable laws and regulations.

This policy applies to all raia assets utilized by personnel acting on behalf of raia or accessing its applications, infrastructure, systems, or data. All personnel are required to read, accept, and follow all raia policies and plans.

Data Retention

The time period for which raia must retain customer data depends on the purpose for which it is used. raia must retain customer data for as long as an account is active or in accordance with the agreement(s) between raia and the customer, unless raia is required by law or regulation to dispose of data earlier or retain data longer.

Data Disposal

raia must dispose of customer data within 30 days of a request by a current or former customer or in accordance with the Customer's agreement(s) with raia. raia may retain and use data necessary for the contract such as proof of contract in order to comply with its legal obligations, resolve disputes, and enforce agreements. raia hosting and service providers (such as Google Cloud) are responsible for ensuring the removal of data from disks allocated to raia use before they are repurposed and the destruction of decommissioned hardware.

Only a limited number of raia employees should have access to delete customer data.

Upon employee or contractor termination, company-owned devices will be collected and sanitized prior to device re-issuance in accordance with NIST Guidelines for Media Sanitization (NIST S.P. 800-88 Rev. 1).

GDPR Right to Erasure and Data Subject Rights

In accordance with Article 17 of the General Data Protection Regulation (GDPR), individuals located in the EU/EEA have the right to request erasure of their personal data ("right to be forgotten"). raia must erase personal data without undue delay where:

• The personal data is no longer necessary in relation to the purposes for which it was collected or otherwise processed;
• The data subject withdraws consent and there is no other legal ground for the processing;
• The data subject objects to the processing and there are no overriding legitimate grounds;
• The personal data has been unlawfully processed;
• The personal data must be erased for compliance with a legal obligation; or
• The personal data was collected in relation to the offer of information society services to a child.

Exceptions to Erasure:

The right to erasure does not apply to the extent that processing is necessary for:

• Exercising the right of freedom of expression and information;
• Compliance with a legal obligation requiring processing;
• Reasons of public interest in the area of public health;
• Archiving purposes in the public interest, scientific or historical research, or statistical purposes; or
• The establishment, exercise, or defense of legal claims.

Response Timeline:

raia must respond to erasure requests without undue delay and in any event within one month of receipt of the request. This period may be extended by two further months where necessary, taking into account the complexity and number of requests. raia must inform the data subject of any such extension within one month of receipt of the request.

Notification to Third Parties:

Where raia has made the personal data public or has disclosed it to third-party processors, raia must take reasonable steps to inform those processors that the data subject has requested erasure of any links to, or copies of, that personal data.

Data Portability (GDPR Article 20)

Where processing is based on consent or a contract, and is carried out by automated means, data subjects in the EU/EEA have the right to receive their personal data in a structured, commonly used, and machine-readable format. Where technically feasible, raia will transmit the data directly to another controller at the data subject's request.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

raia

Purpose and Scope

This Encryption and Key Management Policy provides guidance on the types of devices and media that need to be encrypted, when encryption must be used, the minimum standards of the software used for encryption, and the requirements for generating and managing keys at raia. Following documented policy will limit mistakes in selecting keys, implementing the encryption/decryption process, and managing keys and other secrets which are common causes of data exposure.

From time to time, raia may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations. This policy is guided by security requirements specific to raia including applicable laws and regulations.

This policy applies to all raia assets utilized by personnel acting on behalf of raia or accessing its applications, infrastructure, systems, or data. All personnel are required to read, accept, and follow all raia policies and plans.

Cryptographic Key Requirements

raia must use industry-approved strong algorithms for encryption processes for data-in-transit and data-at-rest.

Strong Standards

Transport Layer Security

raia uses strong cryptography and security protocols (TLS 1.2+ or a minimally equivalent protocol) to safeguard sensitive data during transmission over open, public networks. raia protects the integrity and confidentiality of data passing over public networks from fraudulent activity, contract dispute, and unauthorized disclosure and modification.

raia prohibits the transmission of unprotected sensitive data using insecure end-user messaging technologies.

Databases at Rest

raia requires that the encryption of data-at-rest should only include strong encryption methods (AES-256 or a minimally equivalent protocol).

Reference the following for guidance on encryption algorithms: NIST Security Requirements for Cryptographic Modules (FIPS 140-3) and NIST CMVP Approved Security Functions (S.P. 800-140C).

Key Management

Keys must be protected to prevent unauthorized disclosure and subsequent fraudulent use.

• Users handling private keys must physically and logically secure them.
• Do not share keys with anyone else.
• Never re-use keys to encrypt other information.

Generating Keys

To generate a key, users must use an industry-standard random key generating mechanism. Reference OWASP Key Management Cheat Sheet for guidance.

Keys should not be based on common words or phrases.

Key Rotation

Encryption keys should be changed (or rotated) based on a number of different criteria:

• If the key is or may be compromised. For example, an ex-employee may have had access to a key.
• After a specified period of time has elapsed (known as the cryptoperiod). See Section 5.3 of NIST Recommendation for Key Management for guidance.
• After the key has been used to encrypt a specific amount of data.
• If there is a significant change to the security provided by the algorithm (such as a new attack being announced).

Key Storage

When available, the secure storage mechanisms provided by the operating system, framework or cloud service provider should be used. The key management system must ensure that all encryption keys are secured and there is limited access to raia personnel.

This may include:

• A physical Hardware Security Module (HSM)
• A virtual HSM
• Key vaults such as Google Cloud Key Management Service (KMS)

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

Richard Swier or a designee is responsible for ensuring compliance across raia with respect to this policy with the use of a variety of monitoring tools.

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is maintained by Richard Swier.

This document was last updated on May 7, 2026.

HIPAA Privacy Policy and Procedures Manual

raia

HIPAA Privacy Policy and Procedures Manual

1.0 Introduction

1.01 Introduction

The Health Insurance Portability and Accountability Act of 1996, including its regulations implementing certain privacy requirements (the “Privacy Rule”), certain breach notification requirements (the “Breach Notification Rule”), and certain security requirements regarding information transmitted by or maintained in Electronic Media (the “Security Rule”), each as amended from time to time (collectively “HIPAA”), and as enforced by the US Department of Health and Human Services (“HHS”), imposes certain health information obligations on raia (the “Company”) in its role as a Business Associate to Covered Entities or other Business Associates. These obligations concern the privacy and security of individually identifiable health information that raia receives from Covered Entities or their Business Associates, or creates, maintains or transmits on behalf of Covered Entities or their Business Associates.

This HIPAA Privacy Policy and Procedures Manual (the “Policy”) describes the policies and procedures of raia that are intended to comply with the requirements of the Privacy Rule and the Breach Notification rule. raia’s policies and procedures that are intended to comply with the requirements of the Security Rule are set forth in a separate Company manual, the “HIPAA Security Policy and Procedures Manual.”

The Privacy Rule restricts raia’s ability to use and disclose certain individually identifiable health information that is termed “protected health information” or “PHI”. For purposes of this Policy:

Protected Health Information or “PHI” means information that is individually identifiable health information that would be considered “protected health information” under HIPAA, including information received from a Covered Entity or created, received, or maintained on behalf of a Covered Entity and relates to the past, present, or future physical or mental health condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual; and that identifies an individual, or for which there is a reasonable basis to believe the information can be used to identify an individual, including name, date of birth, or social security number. PHI includes information of persons living or who have been deceased for 50 years or less.

Other words and phrases that are capitalized in this Policy, and not specifically defined when used have special meanings that are defined in Section 6 below; provided that any capitalized term not specifically defined in this Policy shall have the same meaning as is set forth in HIPAA, and all words and phrases defined in Section 7 that are also defined in HIPAA are intended to have the same meaning as is set forth in HIPAA.

The Policy consists of seven (7) sections.

Section 1 is an introduction that describes the purpose of the Policy and its organization.

Section 2 describes raia’s policies and procedures for complying with the administrative requirements of the Privacy Rule.

Section 3 describes raia’s policies and procedures for using and disclosing PHI, including procedures for verifying the identity of those requesting PHI.

Section 4 describes raia’s policies and procedures for addressing breach of unsecured PHI.

Section 5 describes raia’s procedures for complying with the Privacy Rule’s documentation requirement.

Section 6 defines key terms that are used in this Policy. The defined terms are capitalized throughout the Policy.

Section 7 contains links to key resources related to the implementation of this Policy, including the text of the HIPAA Privacy Rule and Breach Notification Rule and helpful third-party documents.

It is raia’s policy to comply fully with the Privacy Rule and Breach Notification requirements. To that end, all members of raia’s workforce who have access to PHI to carry out their duties (the “Workforce”) must comply with this Policy. For purposes of this Policy, the Workforce includes individuals who would be considered part of raia’s Workforce under the Privacy Rule, such as employees, volunteers, trainees, and other persons whose work performance is under the direct control of raia, whether or not they are paid by raia. The Policy (or the applicable portions) will be provided to the Workforce who have Access to PHI. These Workforce members will also receive updates that reflect any changes in law or the Policy's procedures. Workforce members can obtain more information from raia’s Privacy Official.

No third party rights (including but not limited to rights of raia employee clients, Covered Entities, or Subcontractors) are created by this Policy. raia reserves the right to amend or change this Policy at any time (and even retroactively) without notice. To the extent this Policy establishes requirements and obligations above and beyond those required by the Privacy Rule and Breach Notification Rule, the Policy will be aspirational and will not be binding upon raia, nor give rise to a violation of the Privacy Rule or the Breach Notification Rule. This Policy does not address requirements under other federal laws or under state laws. Furthermore, this Policy is designed solely to meet the requirements of the Privacy Rule and Breach Notification Rule and serves no purpose under the Employee Retirement Income Security Act of 1974 (“ERISA”). Thus, this Policy shall not be deemed to constitute a contract under any applicable law, is not a health plan document under ERISA, and individuals may not bring a private cause of action based on this Policy or raia’s obligations under the Privacy Rule or Breach Notification Rule.

2.0 Administrative Requirements

2.01 Privacy Official

raia shall at all times have a designated Privacy Official who is responsible for the development and implementation of policies and procedures relating to privacy, including but not limited to this Policy. The Privacy Official will also serve as raia’s contact person who is responsible for receiving complaints regarding raia’s compliance with the Privacy Rule, the Breach Notification Rule and this Policy, and providing further information about matters covered by raia’s Notice of Privacy Rights. Wherever this Policy refers to the Privacy Official such reference will include any person delegated by the Privacy Official, whether such delegation is oral or written.

The Privacy Official is Richard Swier.

[45 C.F.R. § 164.530(a)]

2.02 Workforce Training

a. Policy

The Privacy Official is charged with developing training schedules and programs so that all Workforce members receive the training necessary and appropriate to permit them to carry out their functions for raia.

b. Procedures

All current Workforce members shall be trained regarding the Privacy Rule, the Breach Notification Rule, and applicable procedures.

All new Workforce members will be trained within a reasonable time after joining the Workforce,

Training is presented by the Privacy Official or Security Official. The training includes a series of PHI and HIPAA-related training videos.

If this Policy is materially changed, the Privacy Official will perform a new training session for the Workforce members whose functions are affected by a material change in this Policy or the Privacy Rule or Breach Notification Rule within a reasonable time after the new Policy takes effect.

The Privacy Official shall document that all training has been provided as required (such as through training rosters that show training dates, the subject of the training, and the names of attendees) in accordance with the Policy’s procedures under Section 5.03 (“Documentation”).

[45 C.F.R. § 164.530(b)]

2.03  Administrative, Technical and Physical Safeguards

a. Policy

raia has established and shall implement appropriate administrative, technical and physical safeguards to protect the privacy of PHI. raia shall reasonably safeguard PHI from any intentional or unintentional use or disclosure of PHI that violates the Privacy Rule’s requirements, and shall reasonably safeguard PHI to limit incidental uses or disclosures made pursuant to an otherwise permitted or required use or disclosure.

b. Procedures

While working on a specific document or file, Workforce members will take measures to prevent others from viewing it and keep all other documents containing PHI inside folders or face down;

When Workforce members are away from their workstations during the day, such as breaks and lunch, PHI must be put in a drawer and when leaving for the day, PHI information must be placed in a locked drawer or cabinet;

The number of photocopies made of PHI must be limited;

E-mails containing PHI must be limited to the Minimum Necessary, for example, strings of e-mails containing PHI should not be forwarded;

To assure PHI confidentiality, conversations regarding PHI are not to take place in public or shared spaces, and Workforce members working remotely should ensure they are in a private setting when discussing PHI and should never use speakerphone in environments where others may overhear;

Before speaking to any client employee about his or her PHI, Workforce members must verify the individual’s identity in accordance with Section 3.08 (“Verification of Identity of Those Requesting PHI”);

When on the telephone, Workforce members must lower their voices to prevent others from overhearing conversations regarding PHI;

Documents or files containing PHI must not be stored on personal devices or unsecured locations without the specific advance written approval of the Privacy Official, which shall record all pertinent information to track the transaction. Any physical documents generated during client engagements shall be securely stored and returned to a designated secure location as soon as practicable;

Documents with PHI, which are distributed internally, must be clearly labeled as "CONFIDENTIAL, CONTAINS PHI" and transmitted only via approved encrypted channels;

Social Security numbers must not be used as identifiers in e-mails;

All physical documents containing PHI must be securely shredded using a cross-cut shredder before disposal. Remote workers must maintain a personal cross-cut shredder or use a certified document destruction service;

A password is not to be written where someone can see it or find it and passwords are never to be shared with anyone including managers or IT staff;

A Workforce member’s computer must be locked before the Workforce member leaves the workstation;

Telephone calls are not to be monitored with speaker or speakerphones on. When it is necessary to monitor or listen to audible sources of PHI all necessary precautions must be taken to protect the privacy of those communications; and

Only authorized personnel are permitted access to systems and workspaces containing PHI. When working in shared or co-working spaces, reasonable steps must be taken to avoid exposing others to PHI, including the use of privacy screens and secure document handling.

[45 C.F.R. § 164.530(c)]

2.04  Complaints

a. Policy

The Privacy Official will be raia’s contact person for receiving complaints about this Policy, and raia’s compliance with this Policy or the requirements of the Privacy Rule or Breach Notification Rule, and for handling such complaints.

b. Procedures

The Privacy Official will review and handle complaints.

The Privacy Official will document complaints received and their resolutions in accordance with the Policy’s procedures under Section 5.03 (“Documentation”).

[45 C.F.R. § 164.530(d)]

2.05  Sanctions

a. Policy

Sanctions against Workforce members for using or disclosing PHI in violation of this Policy, or the requirements of the Privacy Rule or the Breach Notification Rule (subject to protections afforded to whistleblowers, and in compliance with applicable anti-retaliation requirements set forth in Section 2.06) will be imposed in accordance with raia’s discipline policy, as outlined in the Employee Handbook.

b. Procedures

During training, Workforce members are informed that sanctions may be imposed if the Policy is violated.

Appropriate sanctions will be determined based on the nature of the violation, its severity, and whether it was intentional or unintentional. Such sanctions may include, without limitation, verbal counseling, written warnings, probationary periods and/or termination of employment.

Application of any sanctions will be documented in accordance with the Policy’s procedures under Section 5.03 (“Documentation”).

[45 CFR § 164.530(e)]

2.06  No Intimidating or Retaliatory Acts; No Waiver of the Privacy Rule

a. Policy

raia, in compliance with HIPAA, shall not and no Workforce member shall intimidate, threaten, coerce, discriminate against, or take other retaliatory action against any individual or other person: (i) for the exercise of any right established, or for participation in any process provided for by the Privacy Rule or Breach Notification Rule, or (ii) for filing a complaint under HIPAA, or (iii) for testifying, assisting or participating in an investigation, compliance review, proceeding or hearing under HIPAA, or (iv) for opposing any act or practice made unlawful by HIPAA, provided the individual or person has a good faith belief that the practice opposed is unlawful, and the manner of opposition is reasonable and does not involve a disclosure of PHI in violation of the Privacy Rule. In addition, raia shall not require individuals to waive their rights under HIPAA to make a complaint to the Secretary of HHS, or any right under the Privacy Rule or the Breach Notification Rule, as a condition of the provision of treatment, payment, enrollment in a health plan, or eligibility for benefits

b. Procedure

If a Workforce member or other person becomes aware of a violation of the foregoing prohibitions against intimidation, retaliation, etc., the Workforce member or other person will promptly (but not later than 24 hours) notify the Privacy Official.

[45 CFR §§ 164.530(g), (h)]

3.0 Uses and Disclosures of PHI

3.01  Business Associate Uses and Disclosures of PHI

a. Policy

As a Business Associate, raia may use or disclose PHI only as permitted or required by its Business Associate Agreement with a Covered Entity or as required by law. raia may also use and disclose PHI for the proper management and administration of raia so long as such uses or disclosures are permitted under the Business Associate Agreement with a Covered Entity.

b. Procedures

raia will comply with the following requirements as set forth in a Business Associate Agreement:

Use appropriate safeguards to prevent use or disclosure of PHI as set forth in raia’s HIPAA Security Policy and Procedures Manual;

Report to a Covered Entity any use or disclosure of PHI not provided for in the Business Associate Agreement of which it becomes aware, including breaches of unsecured PHI as further set forth in Section 4 (“Breaches of Unsecured PHI”);

Ensure that any subcontractors that create or receive, maintain, or transmit PHI on behalf of raia agree to the same restrictions and conditions that apply to raia with respect to such PHI as further set forth in Section 3.04 (“Disclosures of PHI to Subcontractors”);

Disclose and amend an individual’s PHI as set forth in Section 3.02 (“Mandatory Disclosure of PHI to the Individual”) and Section 3.03 (“Individuals’ Access to PHI and Requests for Copies or Amendments”);

Make available to the Covered Entity the information needed for the Covered Entity to provide an accounting of disclosures as required by the Privacy Rule;

To the extent raia is to carry out a Covered Entity's Privacy Rule obligations, raia will not use or disclose PHI in a manner that would violate the Privacy Rule, if done by the Covered Entity;

Make reasonable efforts to limit PHI to the “minimum necessary” to accomplish the intended purpose of the use, disclosure or request;

Make its internal practices and records related to the use and disclosure of PHI available to HHS for purposes of determining a Covered Entity’s compliance with the Privacy Rule; and

Return or destroy PHI at the termination of a contract with a Covered Entity, if feasible, or if such return or destruction is not feasible, extend the protections of the PHI set forth in the Business Associate Agreement to the PHI and limit further uses and disclosures.

[45 C.F.R. § 164.502(a)(3); 45 C.F.R. § 164.504(e)(2)(ii)]

3.02 Mandatory Disclosures of PHI to the Individual

a. Policy

An individual’s PHI must be disclosed to the individual who is the subject of the information as required by the Privacy Rule.

b. Procedures

Follow the procedures for verifying the identity of the individual as set forth at Section 3.08 (“Verification of Identity of Those Requesting PHI”); and

Follow the procedures set at Section 3.03 (“Individuals’ Access to PHI and Requests for Copies or Amendments”).

3.03 Individuals’ Access to PHI and Requests for Copies or Amendments

a. Policy

The Privacy Rule gives individuals the right to access and obtain copies of their PHI that raia maintains in designated record sets. The Privacy Rule also provides that individuals may request to have their PHI amended. raia will only consider requests for access or amendments that are submitted in writing.

A “Designated Record Set,” for purposes of this Policy, is defined as in the Privacy Rule and consists of a particular group of “records” maintained by raia or for a Covered Entity. “Records” mean any item, collection or grouping of information that includes PHI and is maintained, collected, used or disseminated by or for a Covered Entity.

b. Procedures

Requests for Access to and/or Copy of PHI. Upon receiving a written request from an individual (or a minor’s parent or an individual’s authorized personal representative under applicable law) for access to an individual’s PHI held in a designated record set, the Workforce member must take the following steps:

Follow the procedures for verifying the identity and, as applicable, the authority of the requester, as set forth in Section 3.08 (“Verification of Identity of Those Requesting PHI”).

Review the disclosure request, including by consulting and coordinating with Covered Entities and Subcontractors, as applicable. This will include a review to determine whether the PHI at issue is held in a Designated Record Set of raia, a Covered Entity, a Business Associate or a Company Subcontractor. It will also include a review to determine whether an exception to the disclosure requirement might exist under the Privacy Rule; for example, disclosure may be denied for requests to access psychotherapy notes, documents compiled for a legal proceeding, certain requests by inmates, information compiled during research when the individual has denied access, information obtained under a promise of confidentiality, and other disclosures that are determined by a health care professional to be likely to cause harm. All Workforce member determinations to approve or deny access must be reviewed and approved by the Privacy Official.

Respond to the request, including by consulting and coordinating with Covered Entities, Business Associates and Subcontractors, as applicable. This will include providing the information or denying the request within 30 days. If the requested PHI cannot be accessed within the 30-day period, the deadline may be extended for no more than 30 days by providing written notice to the individual within the original 30-day period of the reasons for the extension and the date by which the Plan will respond.

A denial notice must comply with Privacy Rule requirements, including by containing: (i) the basis for the denial; (ii) a statement of the individual’s right to request a review of the denial, if applicable; and (iii) a statement of how the individual may file a complaint concerning the denial. All notices of denial must be prepared or approved by the Privacy Official.

If the request is approved, provide the information requested, in the form and format requested by the individual, if readily producible in such form. Otherwise, provide the information in a readable hard copy or such other form and format as is agreed to by the individual, except that if the requested PHI is maintained electronically, and the request is made for an electronic copy, raia must provide the PHI in the electronic form and format requested, if it is readily producible in such form and format; or, if not, in a readable electronic form and format as agreed to by raia and the individual. Individuals have the right to receive a copy directly by mail or come in and pick up a copy. Individuals also have the right to come in and inspect the information.

If the individual has requested a summary and explanation of the requested information in lieu of, or in addition to, the full information (including agreeing in advance to the fees imposed, if any, by raia, for the summary and explanation), prepare such summary and explanation of the information requested, and make it available to the individual in the form or format requested by the individual. All such statements must be reviewed and approved by the Privacy Official.

If the individual’s request for access directs raia to transmit the PHI directly to another person designated by the individual, the Workforce member shall provide the copy to the person designated by the individual. This designation must be in writing, signed by the individual, and clearly identify the designated person and where to send the copy of PHI. Any such requests shall be reviewed and approved by the Privacy Official.

Charge a reasonable cost-based fee for copying, postage, and preparing a summary, which shall include the costs for supplies for electronic media if the individual requests that the electronic copy be provided on portable media. The calculation of this fee may include consulting and coordinating with Covered Entities, Business Associates, or Subcontractors, as applicable. The fee for preparing a summary must be agreed to in advance by the individual.

Disclosure requests and associated matters must be documented in accordance with the Policy’s procedures under Section 5.03 (“Documentation”).

Request to Amend PHI. Upon receiving a written request from an individual (or a minor’s parent or an individual’s authorized personal representative under applicable law) for amendment of an individual’s PHI held in a Designated Record Set, the Workforce member must take the following steps:

Follow the procedures for verifying the identity, and as applicable, the authority of the requester as set forth in Section 3.08 (“Verification of Identity of Those Requesting PHI”);

Review the request for amendment, including by consulting and coordinating with Covered Entities, Business Associates and Subcontractors, as applicable. This will include determining whether the PHI at issue is held in a Designated Record Set of the Plan or a Business Associate (or its subcontractors). It will also include reviewing the request for amendment, to determine whether the amendment is appropriate under the Privacy Rule, including regarding whether the PHI was created by the Plan or a Business Associate (or its subcontractors), would be available for access and inspection by the individual under subparagraph (i), above; and is accurate and complete without the amendment. All Workforce member determinations to approve or deny an amendment requests must be reviewed and approved by the Privacy Official.

Respond to the request, including by consulting and coordinating with Covered Entities, Business Associates and Subcontractors, as applicable. This will include responding within 60 days by informing the individual in writing that the amendment will be made or that the request is denied. If the determination cannot be made within the 60-day period, the deadline may be extended for no more than 30 days by providing written notice to the individual within the original 60day period of the reasons for the extension and the date by which raia will respond.

When an amendment is accepted, make appropriate changes and notations in the applicable Designated Record Set in accordance with Privacy Rule requirements. All such notations and changes must be reviewed and approved by the Privacy Official.

With respect to all approved amendments, in accordance with Privacy Rule requirements, and within the time period specified in subparagraph (c), above, provide appropriate notice to the individual of the amendment, and obtain the individual's identification and agreement regarding persons who have received the applicable PHI and require the amendment. Also, raia shall make reasonable efforts to identify and notify within a reasonable time other persons/entities who are known to have the particular record (e.g.,Covered Entities, other Business Associates or Subcontractors) and who may rely on the uncorrected information to the detriment of the individual.

When an amendment request is denied, the following procedures apply:

A denial notice must comply with Privacy Rule requirements, including by containing (i) the basis for the denial; (ii) information about the individual’s right to submit a written statement disagreeing with the denial and how to file such a statement; (iii) an explanation that the individual may (if he or she does not file a statement of disagreement) request that the request for amendment and its denial be included in future disclosures of the information; and (iv) a statement of how the individual may file a complaint concerning the denial. All notices of denial must be prepared or approved by the Privacy Official;

The Privacy Official shall be responsible for assuring that raia complies with all HIPAA Privacy Rule requirements regarding any individual's statement of disagreement and shall coordinate any Company rebuttal/response to such statement of disagreement, including, without limitation, all record-keeping requirements with respect to such matters.

Amendment requests and associated matters must be documented in accordance with the Policy’s procedures under Section 5.03 (“Documentation”).

[45 C.F.R. § 164.524; 45 C.F.R. § 164.526]

3.04 Disclosures of PHI to Subcontractors

a. Policy

Workforce members may disclose PHI to raia’s Subcontractors, subject to certain safeguards, including the execution of a Business Associate Agreement that satisfies the Privacy Rule requirements.

b. Procedures

All uses and disclosures by a Subcontractor must be made in accordance with a valid Business Associate Agreement between raia and the Subcontractor. The Privacy Official shall provide management with a list of Subcontractors to whom PHI may be disclosed, and a form Business Associate Agreement to be used with Subcontractors. Changes to the form Business Associate Agreement must be approved by the Privacy Official. Before providing PHI to a Subcontractor, Workforce members must verify that the Subcontractor is on such list;

The following additional procedures must be satisfied:

Disclosures must be consistent with the terms of the Business Associate Agreement; and

Disclosures must comply with Section 3.07 (“Complying with the Minimum Necessary Standards”).

Evidence of the Subcontractor’s Agreement to safeguard PHI must be documented in accordance with the Policy’s procedures under Section 5.03 (“Documentation”);

If a Workforce member becomes aware of a pattern of activity or practice that may be a material breach or violation of the Subcontractor’s obligations under its Business Associate Agreement, this Policy or the Privacy Rule, the Workforce member should notify the Privacy Official. The Privacy Official will assess the situation and, in particular, determine if there has been a material breach or violation of the Subcontractor’s obligations under its Business Associate Agreement, and take reasonable steps to cure the breach or end the violation, as applicable. If such steps are unsuccessful, the Privacy Official will take any additional reasonable steps to cure the breach or end the violation, as applicable. If such steps are unsuccessful, raia will terminate the Business Associate Agreement, if feasible. In addition, further appropriate action will be taken, for example, determining if the violation falls within Section 4 (“Breaches of Unsecured PHI”).

[45 C.F.R. § 164.502(e)(1)(ii)]

3.05 Disclosure of PHI With Authorization

a. Policy

raia may make disclosures of PHI not otherwise permitted under the Privacy Rule when authorized by the individual whose PHI will be disclosed (or by the personal representative of the individual). PHI may be disclosed for any purpose if an authorization that satisfies all of the Privacy Rule’s requirements for a valid authorization is provided. All uses and disclosures made pursuant to a signed authorization must be consistent with the terms and conditions of the authorization.

b. Procedures

Any requested disclosure to a third party that does not fall within one of the categories for which disclosure is permitted or required (i.e., the individual to whom the PHI pertains or the relevant Covered Entity) may be made pursuant to an individual authorization. In addition, except for certain narrow exceptions permitted by law (such as legal defense), raia, in compliance with the Privacy Rule, will not use or disclose PHI that is a mental health professional’s psychotherapy notes (discrete notes that document the contents of conversation during counseling sessions) without prior authorization, and will not use or disclose PHI for any paid marketing activities, or sell PHI without prior authorization.

If an authorization is requested, the following procedures will be followed:

Following the procedures for verifying the identity of the individual (or the individual’s representatives) set forth in Section 3.08 (“Verification of Identity of Those Requesting PHI”).

Prior to any use or disclosure of information pursuant to an authorization, the Privacy Official shall verify that the authorization form is valid in accordance with the Privacy Rule. Generally, valid authorization forms are those that:

Are properly signed and dated by the individual or the individual’s representative;

Are not expired or revoked. The expiration date of the authorization form must be a specific date or a specific time period (e.g., one year from the date of signature), or an event directly relevant to the individual or the purpose of the use or disclosure;

Contain a description of the information to be used or disclosed;

Contain the name of the entity or person authorized to use or disclose the PHI;

Contain the name of the recipient of the use or disclosure;

Contain a statement regarding the individual’s right to revoke the authorization and the procedures for revoking authorizations;

Contain a statement regarding the possibility for a subsequent redisclosure of the information.

A copy of the authorization should be provided to the authorizing individual unless the individual indicates on the authorization form that he/she does not want a copy;

All uses and disclosures made pursuant to an authorization must be consistent with the terms and conditions of the authorization;

A copy of each verified and signed authorization shall be documented in accordance with the Policy’s procedures under Section 5.03 (“Documentation”);

If the authorization is revoked or expired, subsequent uses and disclosures only permitted by an authorization should cease until a new authorization is executed.

[45 C.F.R. § 164.502(a)(1)(iv); 45 C.F.R. § 164.508]

3.06 Disclosures of De-Identified Information

a. Policy

raia may use and disclose information that has been de-identified in accordance with the Privacy Rule. Generally, de-identified information is health information that does not identify an individual and with respect to which there is no reasonable basis to believe that the information can be used to identify an individual. There are two ways raia can determine that information is de-identified: either by professional statistical analysis, or by removing the specific identifiers listed below. Workforce members should consult with the Privacy Official with any specific questions regarding the de-identification of PHI in accordance with the Privacy Rule. Generally, the identifiers that must be removed are as follows:

Names;

All geographic subdivisions smaller than a state;

All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older;

Telephone numbers;

Fax numbers;

Electronic mail addresses;

Social security numbers;

Medical record numbers;

Health Plan beneficiary numbers;

Account numbers;

Certificate/license numbers;

Vehicle identification and serial numbers, including license plate numbers;

Device identifiers and serial numbers;

Web Universal Resource Locators (URLs);

Internet Protocol (IP) address numbers;

Biometric identifiers, including finger and voice prints;

Full face photographic images and any comparable images; and

Any other unique identifying number, characteristic, or code.

b. Procedures

Workforce members must obtain approval from the Privacy Official for the disclosure of de-identified information. The Privacy Official will verify that the information is de-identified. raia may use and disclose de-identified information. De-identified information is not PHI.

[45 C.F.R. § 164.514(b)]

3.07 Complying with the “Minimum Necessary Standard”

a. Policy

The Privacy Rule generally requires that when raia uses or discloses PHI, or when raia requests PHI from another Business Associate or Covered Entity, raia must make reasonable efforts to limit PHI to the “minimum necessary” to accomplish the intended purpose of the use, disclosure or request.

b. Procedures

Workforce members may reasonably rely on a requested disclosure of PHI as the minimum necessary for the stated purpose if the PHI is requested by a professional who is a member of the Workforce or a Covered Entity for the purpose of providing professional services to the Covered Entity. For all other requests for disclosures of PHI, Workforce members must determine that the amount of information disclosed is the minimum necessary to accomplish the intended purpose of the disclosure. If a Workforce member has a question regarding whether a use or disclosure of PHI meets the minimum necessary standard, he or she is required to consult with the Privacy Official, who shall assist in making the determination.

The minimum necessary standard does not apply to any of the following:

Disclosures made to the individual;

Uses or disclosures made pursuant to an individual authorization;

Disclosures made to HHS;

Uses or disclosures required by law; and

Uses or disclosures required to comply with HIPAA.

If a Workforce member requests PHI from a Covered Entity, such request must be limited to the minimum necessary for the requested purpose;

The Privacy Official shall identify those persons or classes of persons, as appropriate, that are Workforce members and who accordingly need access to PHI to carry out their duties; and for each such person or class of persons, the category or categories of PHI to which access is needed and any conditions appropriate to such access. Documentation of these determinations shall be retained pursuant to Section 5.03 (“Documentation”).

[45 C.F.R. § 164.502(b)]

3.08 Verification of Identity of Those Requesting PHI

a. Policy

raia must verify the identity and authority of individuals requesting PHI before disclosing such PHI.

b. Procedures

Workforce members must take steps to verify the identity of individuals who request PHI. They must also verify the authority of any person to have access to PHI, if the identity or authority of such person is not known. Separate procedures are set forth below for verifying the identity and authority, depending on whether the request is made by the individual, a parent seeking access to the PHI for his or her minor child, an authorized personal representative under applicable law, or a public official.

When an individual requests access to his or her own PHI, the following steps must be followed

If the individual requests PHI in person, Workforce members must request a form of identification. Workforce members may rely on a valid driver’s license, passport or other photo identification issued by a government agency.

If the individual requests PHI over the telephone, the Workforce member must verify the individual’s identity by requesting all of the following information: (i) address, (ii) date of birth, and (iii) Social Security number, or other unique identifier.

When a parent requests access to the PHI of the parent’s minor child, seek verification of the person’s relationship with the child. Such verification may take the form of confirming enrollment of the child in the parent’s health plan as a dependent and no notation in the file that either such child’s information should not be shared with one of the parents or that the minor is considered an “emancipated minor.” However, applicable state or other laws may, in select circumstances, limit parental access to a minor’s PHI for certain sensitive services where a minor is authorized to personally consent to treatment without parental consent (e.g., regarding HIV/AIDS treatment, or treatment for sexually transmitted illness) and the Privacy Official should be consulted regarding parental inquiries with respect to these types of services;

When a personal representative requests access to an individual’s PHI, the following steps should be followed:

Require a copy of a valid power of attorney or other official documentation that authorizes the individual to access the requested PHI under applicable state or other law (such as court-appointment as a guardian or trustee, appointment under a power of attorney or health care proxy, or appointment as executor of an estate). With respect to a living individual, the documentation must grant the personal representative the authority to act on behalf of the individual in making decisions related to health care, which would include decisions relating to payment for health care, and the personal representative may access the individual’s PHI only to the extent that PHI is relevant to the matters on which the personal representative is authorized to represent the individual. For deceased individuals, a person may be a personal representative of a deceased individual if they have the authority to act on behalf of such individual or such individual's estate for any decision, not only decisions related to health care, and would generally be entitled to access all PHI. The Privacy Official should be consulted to verify the authority of the individual to access the requested PHI as a personal representative under the documentation provided;

A copy of the authorizing documentation provided shall be documented in accordance with the Policy’s procedures under Section 5.03 (“Documentation”).

If a public official requests access to PHI, the following steps should be followed to verify the official’s identity and authority:

If the request is made in person, request presentation of an agency identification badge, other official credentials, or other proof of government status. Make a copy of the identification provided and file it with the individual’s designated record set in accordance with the Policy’s procedures Section 5.03 (“Documentation”);

If the request is in writing, verify that the request is on the appropriate government letterhead;

If the request is by a person purporting to act on behalf of a public official, request a written statement on appropriate government letterhead that the person is acting under the government’s authority or other evidence or documentation of agency, such as a contract for services, memorandum of understanding, or purchase order, that establishes that the person is acting on behalf of the public official;

Request a written statement of the legal authority under which the information is requested, or, if a written statement would be impracticable, an oral statement of such legal authority.

In accordance with the Privacy Rule, raia reserves the right to not treat a personal representative as the individual, and to not provide a parent of a minor child with access to the minor child’s PHI, if, in the exercise of professional judgment, raia finds that doing so would not be in the best interest of the individual because of a reasonable belief that the individual has been or may be subject to domestic violence, abuse or neglect by the personal representative or parent, or that doing so would otherwise endanger the individual

3.09 Accounting for Disclosures

a. Policy

raia is required pursuant to its Business Associate Agreements to provide an accounting of certain disclosures of PHI made in the six years prior to the date on which the accounting is requested. raia will maintain and make available the information required to provide an accounting of disclosures to a Covered Entity as necessary to satisfy the Covered Entity’s accounting obligations under the Privacy Rule.

b. Procedures

raia will maintain accounting information for all disclosures of PHI, except disclosures made:

To carry out treatment, payment and health care operations;

To the individual about his or her own PHI;

Pursuant to an individual authorization;

To a spouse, domestic partner, relatives, friends or other persons identified by the individual;

For national security or intelligence purposes;

To correctional institutions or law enforcement when the disclosure was permitted without an authorization; or

As part of a limited data set.

The accounting information maintained by raia for the reportable disclosures must include:

The date of the disclosure;

The name (and if known, the address) of the entity or person to whom the information was disclosed;

A brief statement of the PHI disclosed; and

A brief statement explaining the purpose for the disclosure that reasonably explains the basis for the disclosure. As permitted by the Privacy Official, for certain disclosures, the statement of purpose may be accomplished by providing a copy of the applicable written request for the disclosure.

Upon receiving a request from a Covered Entity for an accounting of disclosures, the Privacy Official will promptly respond to the request.

4.0 Breaches of Unsecured PHI

4.01 Determination of a Breach of Unsecured PHI

a. Policy

Because raia maintains, accesses, stores, destroys, and otherwise uses and discloses unsecured PHI, raia will diligently address all actual or suspected unauthorized uses or disclosures of PHI.

b. Procedures

Any Workforce member who becomes aware of an actual or suspected unauthorized use or disclosure of PHI held by raia or any of its Subcontractors, or any other actual or suspected unauthorized use, disclosure, loss theft, or alteration of PHI by or on behalf of raia must notify the Privacy Official immediately, but in no case later than 24 hours after the incident or Breach is suspect or identified.

The Privacy Official will immediately undertake an investigation to determinate if the unauthorized use or disclosure constitutes a “Breach of Unsecured PHI” under HIPAA. All such investigations and assessment of suspect or actual Breaches by raia or its Subcontractors will be documented, and maintained on file by the Privacy Official, for at least six (6) years from the date of the incident, in accordance with the Policy’s procedures under Section 5.03 (“Documentation”).

A Breach does not include:

Any unintentional acquisition, access, or use of PHI by a Workforce member or person acting under the authority of raia or its Subcontractors, if made in good faith and within the scope of authority, which does not result in further use or disclosure in a manner not permitted under the Privacy Rule;

Any inadvertent disclosure by a person who is authorized to access PHI at raia or its Subcontractor to another person authorized to access PHI at raia or same Subcontractor, and the information received as a result of such disclosure is not further used or disclosed in a manner not permitted under the Privacy Rule; or

Any disclosure of PHI where raia or its Subcontractor has a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain such information.

Any such finding will be reviewed and approved by the Privacy Official, who may consult with attorneys for raia to make such finding.

Except for the exclusions listed in subparagraph (iii), above, an acquisition, access, use, or disclosure of PHI in a manner not permitted under the Privacy Rule is presumed to be a Breach unless the Covered Entity or raia, as applicable, demonstrates that there is a low probability that the PHI has been compromised based on a risk assessment of at least the following factors:

The nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification;

The unauthorized person who used the PHI or to whom the disclosure was made;

Whether the PHI was actually acquired or viewed; and

The extent to which the risk to the PHI has been mitigated.

[45 C.F.R. § 164.402]

4.02 Notification of Breach

a. Policy

raia shall, following the discovery of a breach of unsecured PHI, notify the Covered Entity of such breach. A breach shall be treated as discovered by raia as of the first day on which such breach is known to the business associate or, by exercising reasonable diligence, would have been known to the business associate. raia shall be deemed to have knowledge of a breach if the breach is known, or by exercising reasonable diligence would have been known, to any person, other than the person committing the breach, who is an employee, officer, or other agent of raia.

b. Procedures

raia shall provide notification of a breach or a suspected breach in accordance with any applicable Business Associate Agreements, and, in all events, without unreasonable delay and in no case later than 60 calendar days after discovery of a breach.

The notification shall include, to the extent possible, the identification of each individual whose unsecured PHI has been, or is reasonably believed by raia to have been accessed, acquired, used, or disclosed during the breach or suspected breach. raia shall provide the Covered Entity with any other available information that the Covered Entity is required to include in a notification to the individual required by the Privacy Rule at the time of notification or promptly thereafter as information becomes available.

[45 C.F.R. § 164.410]

4.03 Mitigation and Remediation of Inadvertent Disclosures of PHI and Breaches

a. Policy

raia will mitigate, to the extent practicable, any harmful effects that become known to raia of a use or disclosure of PHI in violation of this Policy or the requirements of the Privacy Rule by raia or its Subcontracts.

b. Procedures

Inadvertent Disclosure. If a Workforce member becomes aware of a disclosure of PHI, either by a Workforce member or a Subcontractor, that is or is suspected to be not in compliance with this Policy or the privacy Rule, the Workforce must immediately (but not later than 24 hours) contact the Privacy Official so that the appropriate steps to the mitigate the harm can be taken.

Breach.Any Workforce member who becomes aware of an actual or suspected unauthorized use or disclosure of PHI held by raia or any of its Subcontractors, or any other actual or suspected unauthorized use, disclosure, loss theft, or alteration of PHI by or on behalf of raia must notify the Privacy Official immediately, but in no case later than 24 hours after the incident or Breach is suspect or identified. The Privacy Official, in consultation with raia attorneys, will be responsible for determining what steps should be taken to mitigate the effects of any Breaches (e.g., credit monitoring, retraining of relevant Workforce members, and what remedial steps should be taken to avoid similar future events (e.g., retraining of Workforce members, instituting new procedures, engaging alternative Subcontractors).

All mitigation and remedial steps must be documented by the Privacy Official and maintained on file for at least six (6) years from the date of the incident, in accordance with the Policy’s procedures set forth at Section 5.03 (“Documentation”).

[45 C.F.R. § 164.530(f)]

5.0 Required Legal Documents

5.01 Business Associates Agreements

a. Policy

raia shall have a Business Associate Agreement with all Covered Entities and Subcontractors that establish the permitted and required uses and disclosures of PHI by raia. The Business Associate Agreement will not authorize raia to use or further disclose PHI in a manner that would violate the requirements of the Privacy Rule, if done by the covered entity, except that:

The Business Associate Agreement may permit raia to use and disclose PHI from the proper management and administration of its business; and

The Business Associate Agreement may permit raia to provide data aggregation services relating to the health care operations of the Covered Entity.

b. Procedures

raia will obtain signed Business Associate Agreements that comply with HIPAA from all Covered Entities and Subcontractors.

If a Workforce member knows or suspects that a Covered Entity or a Subcontractor is violating the terms of its Business Associate Agreement, the Workforce member must promptly notify the Privacy Official and the Privacy Official must determine if a breach has occurred, if the breach can be cured, and must take any other actions that are indicated under HIPAA and otherwise appropriate.

5.02 Policies and Procedures

a. Policy

raia’s privacy policies and procedures are documented and maintained for at least six years from the later of the date of creation or when it was last in effect, whichever is later. Policies and procedures are changed as necessary and appropriate to comply with changes in the law, including the standards, requirements and implementation specifications of the Privacy Rule or Breach Notification Rule. Any changes to policies or procedures are promptly documented.

b. Procedures

The Privacy Official shall maintain copies of the following:

raia’s HIPAA Security Policies and Procedures Manual;

raia’s HIPAA Privacy Security Policies and Procedures Manual;

Records of HIPAA Training;

Sanctions applied to Workforce members who violate raia’s HIPAA policies and procedures;

Business Associate Agreements and lists of Covered Entities and Subcontractors;

Complaints and resolutions;

Records regarding Workforce member access to PHI; and

Records regarding Breaches of Unsecured PHI.

5.03 Documentation

a. Policy

raia will comply with the Privacy Rule requirements regarding documentation creation and retention.

b. Procedures

Document Retention: raia will retain all documentation required by the HIPAA Privacy Rule for 6 years from the later of the date of its creation or the date when it was last in effect, whichever is later.

Availability: raia will make documentation available to those persons responsible for implementing the procedures, set forth in this Policy, to which the documentation pertains.

Updates: raia will periodically review HIPAA privacy documents and documentation, and update the documents and documentation, as needed.

6.0 Glossary

Access: The ability or the means necessary to read, write, modify, or communicate data/information or otherwise use any system resource.

Business Associate: A person or entity that performs a function or activity regulated by HIPAA on behalf of a Covered Entity and involving PHI. Examples of such functions or activities are claims processing, legal, actuarial, accounting, consulting, data aggregation, management, administrative, accreditation, and financial services. A Business Associate may be a Covered Entity.

Covered Entity: A health plan (including an employer plan, insurer, HMO, and government coverage such as Medicare); a health care provider (such as a doctor, hospital, or pharmacy) that electronically transmits any health information in connection with a transaction for which HHS has established an electronic data interchange standard; and a health care clearinghouse (an entity that translates electronic information between nonstandard and HIPAA standard transactions). The Covered Entities most likely to work with raia are health insurance plans and carriers and their business associates. The HIPAA Privacy Rule requires that each Business Associate enter into a written contract (Business Associate Agreement) with a Covered Entity and Subcontractors regarding PHI.

Disclosure: The release, transfer, provision of, access to, or divulging in any other manner of information outside the entity holding the information.

Encryption: The use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key.

HHS: The United States Department of Health and Human Services.

Information System: An interconnected set of information resources under the same direct management control that shares common functionality. A system normally includes hardware, software, information, data, applications, communications, and people.

Subcontractor: A person to whom a Business Associate delegates a function, activity or service, other than in the capacity of a member of the workforce of such Business Associate.

Workforce:Individuals who would be considered part of raia’s workforce under the Privacy Rule, such as employees, volunteers, trainees, and other persons whose work performance is under the direct control of raia, whether or not they are paid by raia and who have Access to PHI.

Workstation: An electronic computing device, for example, a laptop or desktop computer, or any other device that performs similar functions and Electronic Media stored in its immediate environment.

7.0 Key Resources

7.01 HIPAA Privacy Rule

http://www.hhs.gov/hipaa/for-professionals/privacy/index.html

7.02 HIPAA Breach Notification Rule

http://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html

7.03 Other Resources

a. HHS Privacy Rule Guidance

http://www.hhs.gov/hipaa/for-professionals/privacy/guidance/significant-aspects/index.html

b. HHS Breach Notification Rule Guidance

http://www.hhs.gov/hipaa/for-professionals/breach-notification/guidance/index.html

https://www.hhs.gov/hipaa/for-professionals/breach-notification/breach-reporting/index.html

8.0 Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

9.0 Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

10.0 Responsibility, Review, and Audit

This plan will be reviewed and tested on an annual basis. Ensuring that the plan reflects ongoing changes to resources is crucial. This task includes updating the plan and revising this document to reflect updates; testing the updates; and training personnel. Test results will be documented and signed off by raia management. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is tested, maintained and enforced by Richard Swier.

This document was last updated on May 6, 2026.

raia

1.0 Introduction

1.01 Introduction

The Health Insurance Portability and Accountability Act of 1996, including its regulations implementing certain privacy requirements (the “Privacy Rule”), certain breach notification requirements (the “Breach Notification Rule”), and certain security requirements regarding information transmitted by or maintained in Electronic Media (the “Security Rule”), each as amended from time to time (collectively “HIPAA”), and as enforced by the US Department of Health and Human Services (“HHS”), imposes certain health information obligations on raia acting in its capacity as a Business Associate to Covered Entities and other Business Associates. These obligations concern the privacy and security of individually identifiable health information that raia receives from Covered Entities or creates, maintains or transmits on behalf of Covered Entities.

This HIPAA Security Policy and Procedures Manual (the “Policy”) describes the policies and procedures of raia that are intended to comply with the requirements of the Security Rule. raia’s policies and procedures that are intended to comply with the requirements of the Privacy Rule and the Breach Notification Rule are set forth in a separate raia manual, the “HIPAA Privacy Policy and Procedures Manual.”

This Policy contains policies and procedures with respect to Protected Health Information or “PHI,” but only PHI that is Electronic Protected Health Information under the Security Rule; which is information transmitted by or maintained in Electronic Media. For purposes of this Policy:

Protected Health Information or “PHI” means information that is individually identifiable health information that would be considered “protected health information” under HIPAA, including information received from a Covered Entity or created, received, or maintained on behalf of a Covered Entity and relates to the past, present, or future physical or mental health condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual; and that identifies an individual, or for which there is a reasonable basis to believe the information can be used to identify an individual, including name, date of birth, or social security number. PHI includes information of persons living or who have been deceased for 50 years or less.

Electronic Media means media that would be considered “electronic media” under HIPAA, including (1) electronic storage media on which data is or may be recorded electronically, including, for example, devices in computers (hard drives) and any removable/transportable digital memory medium, such as magnetic tape or disk, optical disk, or digital memory card; and (2) transmission media used to exchange information already in electronic storage media. Transmission media include, for example, the internet, extranet or intranet, leased lines, dial-up lines, private networks, and the physical movement of removable/transportable electronic storage media. Certain transmissions, including paper, via facsimile, and voice via telephone, are not considered to be transmissions via Electronic Media if the information being exchanged did not exist in electronic form immediately before the transmission.

Other words and phrases that are capitalized in this Policy, and not specifically defined when used have special meanings that are defined in Section 8 below; provided that any capitalized term not specifically defined in this Policy shall have the same meaning as is set forth in HIPAA, and all words and phrases defined in Section 8 that are also defined in HIPAA are intended to have the same meaning as is set forth in HIPAA.

The Policy consists of nine (9) sections.

Section 1 is an introduction that describes the purpose of the Policy and its organization.

Section 2 describes raia’s overall policy for protecting PHI.

Section 3 describes raia’s procedures for implementing Administrative Safeguards.

Section 4 describes raia’s procedures for implementing Physical Safeguards.

Section 5 describes raia’s procedures for implementing Technical Safeguards.

Section 6 describes required legal documents including Business Associate Agreements and a description of the Security Rule documentation requirements.

Section 7 describes raia’s policies and procedures for complaints and its prohibition on retaliatory acts.

Section 8 defines key terms that are used in this Policy. The defined terms are capitalized throughout the Policy.

Section 9 contains links to key resources related to the implementation of this Policy, including the text of the HIPAA Security Rule and helpful third-party documents.

It is raia’s policy to comply fully with the Security Rule’s requirements. To that end, all members of raia’s workforce who have access to PHI to carry out their duties (the “Workforce”) must comply with this Policy. For purposes of this Policy, the Workforce includes individuals who would be considered part of raia’s Workforce under the Privacy Rule, such as employees, volunteers, trainees, and other persons whose work performance is under the direct control of raia, whether or not they are paid by raia. The Policy (or the applicable portions) will be provided to the Workforce who have Access to PHI. These Workforce members will also receive updates that reflect any changes in law or the Policy’s procedures. Workforce members can obtain more information from raia’s Security Official.

No third party rights (including but not limited to rights of raia, employees, clients, Covered Entities, or Subcontractors) are created by this Policy. raia reserves the right to amend or change this Policy at any time (and even retroactively) without notice. To the extent this Policy establishes requirements and obligations above and beyond those required by the Security Rule, the Policy will be aspirational and will not be binding upon raia, nor give rise to a violation of the Security Rule. This Policy does not address requirements under other federal laws or under state laws. Furthermore, this Policy is designed solely to meet the Security Rule’s requirements and serves no purpose under the Employee Retirement Income Security Act of 1974 (“ERISA”). Thus, this Policy shall not be deemed to constitute a contract under any applicable law, is not a health plan document under ERISA, and individuals may not bring a private cause of action based on this Policy or raia’s obligations under the Security Rule.

2.0 Statement of Security Policy

2.01 Statement of Security Policy

raia will secure electronic health information (known as PHI) in accordance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA). It is raia’s policy to:

Ensure the Confidentiality, Integrity, and Availability of raia’s PHI;

Protect against any reasonably anticipated Threats or hazards to the security or Integrity of the PHI;

Protect against any reasonably anticipated uses or Disclosures that are not permitted by the HIPAA Privacy Rule; and

Ensure Workforce compliance.

raia will maintain a security infrastructure containing Administrative, Physical, and Technical Safeguards for PHI.

When PHI is shared with a Subcontractor providing services to raia, raia will obtain satisfactory assurances from the Subcontractor that it will appropriately safeguard PHI it creates, receives, maintains, or transmits on raia’s behalf.

3.0 Administrative Safeguards

3.01 Overview

raia maintains procedures to manage risks to its PHI, to control Access to its PHI, to train Workforce members regarding PHI protections, to resolve security incidents that may be a Threat to its PHI, and to protect PHI during emergency situations. The Administrative Safeguards include the following sections of this Policy:

Section 3.02 - Security Management Process

raia will maintain procedures to prevent, detect, and correct security violations. This process will include a risk analysis, ongoing risk management, enforcement of a sanction policy, and review of Information System activity.

Section 3.03 - Assigned Security Responsibility

raia will designate a single individual who has overall responsibility for the development and implementation of the Policies and Procedures required by the Security Rule and this Policy for the security of its PHI.

Section 3.04 - Workforce Security

raia will maintain Workforce security measures to assure that all Workforce members with Access to PHI have the appropriate Access authority and clearances, and to prevent Access by those who do not.

Section 3.05 - Information Access Management

raia will define Access control for all Workforce members authorized to Access PHI and maintain procedures for granting and modifying Access.

Section 3.06 - Security Awareness and Training

raia will maintain a security awareness and training program for all Workforce members with Access to PHI.

Section 3.07 - Security Incident Procedures

raia will maintain procedures to handle security incidents, including identification and response plans, mitigation of incidents, and documentation of incidents and their outcomes.

Section 3.08 - Contingency Plan

raia will maintain a contingency plan for responding to emergencies that affect applications and systems containing PHI.

Section 3.09 - Evaluation

raia will perform periodic technical and non-technical evaluations based on the requirements of the Security Rule, and in response to environmental or operational changes.

3.02 Security Management Process

raia maintains a security management process to prevent, detect, contain and correct security violations of applications and/or systems that contain PHI.

a. Risk Analysis (Required)

raia conducts assessments of the potential risks and vulnerabilities to the Confidentiality, Integrity, and Availability of PHI held by raia periodically, as warranted by changes in environmental, technological, or operational conditions. To appropriately consider the potential vulnerabilities to raia’s PHI, raia uses the following risk analysis strategy:

Identify and document all PHI containing systems or applications (repositories);

Identify the potential Threats or vulnerabilities to each repository;

Assign a level of risk to each PHI repository; and

As appropriate, mitigate the risk to each PHI repository.

A PHI repository may be a database, spreadsheet, folder, storage device, document or other form of electronic information. raia will perform periodic inventories at regular intervals to ensure that the risk analysis is up-to-date and accurate.

b. Risk Management (Required)

raia manages risks to its PHI by limiting vulnerabilities, based on its risk analyses, to a reasonable and appropriate level, taking into account the following:

The size, complexity, and capabilities of raia;

raia’s technical infrastructure, hardware, software, and security capabilities;

The costs of security measures; and

The criticality of the PHI potentially affected.

raia will perform a periodic technical and non-technical evaluation, based on the standards set forth in the Security Rule, to ensure that raia’s Policies and Procedures are updated as warranted by changes in raia’s environmental or operational conditions affecting the security of PHI.

c. Sanction Policy (Required)

Sanctions against Workforce members for failing to comply with the policies and procedures of raia set forth in this Policy (subject to protections afforded to whistleblowers, and in compliance with applicable anti-retaliation requirements, see Section 3.10, below) will be imposed in accordance with raia’s discipline policy, as outlined in raia’s Employee Handbook or equivalent. During training, Workforce members will be informed that sanctions may be imposed if the policies and procedures of this Policy are violated. Appropriate sanctions will be determined based on the nature of the violation, its severity, and whether it was intentional or unintentional. Such sanctions may include, without limitation, verbal counseling, written warnings, probationary periods and/or termination of employment.

d. Information System Activity Review (Required)

The following procedures are used to review activity in PHI-containing applications and/or systems in order to appropriately limit PHI access to authorized purposes:

Access to audit logs will be strictly limited to authorized Workforce members;

Specific activities will be tracked, as described in Audit Controls (Section 5.03), and regularly reviewed for suspicious activity;

When internal security scans reveal that a computer system or application that contains PHI (or is connected to a PHI repository) may be vulnerable, the person designated in Section 3.07 will contact the Security Official or his/her designee as soon as possible, and provide a description of the vulnerability and a timeline for securing the vulnerability. Timelines will vary depending on the severity; and

When Auditing tools reveal unusual activity within a computer system or application that contains PHI (or is connected to an PHI repository) the person designated in Section 3.07 will contact the Security Official or his/her designee as soon as possible, and provide a description of the activity and actions taken to mitigate and/or investigate the unusual network activity.

[45 CFR § 164.308(a)(1)]

3.03 Assigned Security Responsibility

raia assigns the oversight of compliance with the Security Rule to the HIPAA Security Official. If raia’s Security Official is unable to meet the requirements or responsibilities under the Security Rule and set forth below, or is no longer affiliated with raia, raia will assign a new Security Official.

The Security Official is captured in Secureframe's settings.

Security Official Objectives

Establish accountability for security of Protected Health Information (PHI) for raia in compliance with HIPAA. The Security Official oversees all ongoing activities related to the development, implementation, maintenance of, and adherence to raia’s policies and procedures covering the security of, and Access to, PHI in compliance with federal and state laws and raia’s information privacy practices.

Security Official Responsibilities

Accountable for developing and implementing security policies and procedures for raia for all members of the Workforce that come in contact with PHI.

Provide development guidance and assist in the identification, implementation, and maintenance of information security policies and procedures in coordination with raia management.

Working and coordinating with raia’s Privacy Official.

Electronic security training and orientation to all Workforce members, contractors, and other appropriate third parties with Access to PHI.

Mitigate the effects of all Disclosures that are not HIPAA compliant or contrary to raia’s security goals.

Cooperate with HHS’s Office of Civil Rights, other legal entities, and raia officers in any compliance review or investigations.

Establish and administer a process for receiving, documenting, tracking, investigating, and taking action on all complaints concerning the policies and procedures of this Policy, and the requirements of the Security Rule.

Work with raia administration to represent raia’s information security interest with external parties (government bodies) who undertake to adopt or amend security legislation, regulation, or standard.

Initiate, facilitate, and promote activities to foster information security awareness within raia.

Conduct continuous risk assessment and analysis. As significant Threats are discovered, management support for additional initiatives and countermeasures will be sought and implemented.

Conduct related ongoing compliance monitoring activities in coordination with raia’s other compliance and operational assessment functions.

Responsible for the PHI security infrastructure of raia.

Identify key security initiatives and standards, (e.g., virus protection, security monitoring, intrusion detection, local and remote Access control policies, and other technical security services and mechanisms).

Establish mechanisms to track Access to PHI as required by law to allow qualified individuals to review.

[45 CFR § 164.308(a)(2)]

3.04 Workforce Security

raia maintains Workforce security procedures to ensure that all raia Workforce members have appropriate Access to PHI. These procedures also are intended to prevent those Workforce members who do not have appropriate Access to PHI from obtaining such Access.

a. Authorization and/or Supervision (Addressable)

A record of those Workforce members who require Access to PHI and the scope of such Access necessary to perform raia administrative functions is maintained by raia IT and Department Managers. Workforce members who do not have Access to PHI but who have a need to review records containing PHI must be supervised in that activity by someone that has such Access and the technical skills to appropriately supervise said Workforce members.

b. Workforce Clearance Procedure (Addressable)

Workforce members that Access PHI are subject to a background check or screening process to ensure that their Access is appropriate. The screening process will include the following checks:

Criminal History

Identity Checks (SSN Verification)

Education and Credential Verification

Credit Reports

Employment and Reference Verification

c. Termination Procedures (Addressable)

If a Workforce member who has Access to PHI is terminated or resigns, the former Workforce member’s computer accounts will be disabled, including any accounts used for database Access, dial-up, or Internet Access from a remote location.

[45 CFR § 164.308(a)(3)]

3.05 Information Access Management

To ensure that appropriate Access to PHI is consistent with the HIPAA Privacy Rule, raia actively manages the rights of Workforce members to Access PHI. To the extent that it is reasonable and appropriate, Access to PHI is limited to Workforce members for purposes of administering raia’s business as permitted by the Privacy Rule and consistent with raia’s policies and procedures.

a. Access Authorization (Addressable)

raia maintains a record of those Workforce members who require Access to PHI and the scope of such Access necessary to perform services for raia clients. The list is maintained by IT and Department Managers.

b. Access Establishment and Modification (Addressable)

raia will review who has Access to PHI and whether such Access is limited to PHI that is minimally necessary to perform raia administrative functions. The PHI Access Control Checklist is reviewed by IT and Department Managers on a semi-annual interval.

[45 CFR § 164.308(a)(4)]

3.06 Security Awareness And Training

raia maintains security awareness and training for all Workforce members with Access to any PHI repository. Workforce members will review raia’s HIPAA Security Policy, as appropriate, prior to receiving Access to any PHI, and when changes to Policy’s policies and procedures occur that are relevant to their job function.

a. Security Reminders (Addressable)

raia will provide Workforce members with periodic security updates.

b. Protection from Malicious Software (Addressable)

raia uses hardware and anti-virus software that scans email attachments and other downloadable files. Every Workstation will have anti-virus software installed and activated. Virus signature files will be routinely updated. Workforce members will be instructed not to open emails unless the message was expected in the course of business or was sent by a source known to the recipient.

c. Log-In Monitoring (Addressable)

raia maintains procedures for monitoring log-in attempts and reporting discrepancies.

For systems containing PHI, logs that track successful logins will be periodically reviewed.

For systems containing PHI, logs that track failed login attempts will be periodically reviewed.

Suspicious login activity will be reported and resolved in accordance with raia’s Security Incident Procedures (Section 3.07).

d. Password Management (Addressable)

Workforce members with access to raia’s PHI will comply with raia’s password management policy.

[45 CFR § 164.308(a)(5)]

3.07 Security Incident Procedures

raia maintains procedures addressing Security Incidents that permit raia to identify and respond to suspected or known Security Incidents, mitigate, to the extent practicable, harmful effects of Security Incidents that are known to raia, and document Security Incidents and their outcomes.

The user of any information technology device connected to or housing PHI will report any suspected or known Security Incident promptly to r@raiaai.com.

The Security Incident Response Team (SIRT) will log all pertinent information regarding a security incident including date, time, people contacted, and PHI applications or repositories affected. A written log will be kept for all Security Incidents. The Privacy Official and the Security Official will promptly notify each other (or his or her designee) in the event of any such reports, and cooperate to address and resolve all such issues in compliance with HIPAA. This shall include, without limitation, that the Privacy Official and the Security Official will promptly notify each other (or his or her designee) in the event of Security Incidents that have compromised PHI which cannot be timely restored from backups or other circumstances where raia’s reliance on the Integrity and Availability of PHI is materially affected.

The Security Official and the Privacy Official shall cooperate to mitigate, to the extent practicable, harmful effects of Security Incidents that are known to raia, and document Security Incidents and their outcomes, and as appropriate if the Security Incident constitutes a reportable data breach in violation of HIPAA Privacy Rules, and in accordance with HIPAA Breach Notification rules.

With respect to each reported incident, the Security Official will ensure that the following actions occur:

Assess the severity of the compromise

If feasible, make a backup of the infected system(s) or application(s) to prevent attacker from removing evidence of his or her activities

If feasible, determine if the hacker has left any programs or files on the infected system(s)

Check all logs for any suspicious activity.

[45 CFR § 164.308(a)(6)]

3.08 Contingency Plan

raia maintains a contingency plan that includes procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems and/or applications containing PHI.

a. Data Backup Plan (Required)

The extent to which a backup plan is needed will be determined by raia’s periodic risk analyses, including categories of PHI that require an exact retrievable copy. Those categories of PHI where regular backups are not maintained are not needed for raia’s continued operation.

b. Disaster Recovery Plan (Required)

raia will restore lost, damaged or destroyed PHI from regularly maintained backups, or other outside sources (e.g., third-party vendors).

c. Emergency Mode Operation Plan (Required)

raia will permit Access control overrides during emergency situations. In addition, to the extent feasible, the following measures are continued during an emergency:

Guards

Lighting

Locks

d. Testing and Revision Procedures (Addressable)

The contingency plan policies and procedures are tested, reviewed and revised as needed, and if necessary, take reasonable steps to ensure that the policies and procedures are up-to-date and effective. In addition, raia’s Business Continuity Plan (BCP) is updated annually and parts of the plan are tested at least annually.

e. Applications and Data Criticality Analysis (Addressable)

See Risk Management (Section 3.02(b)) for raia’s Applications and Data Criticality Analysis procedure.

[45 CFR § 164.308(a)(7)]

3.09 Evaluation

See Risk Management (Section 3.02(b)) for raia’s Evaluation procedure.

[45 CFR § 164.308(a)(8)]

4.0 Physical Safeguards

4.01 Overview

raia maintains procedures to protect applications, systems and related facilities and equipment housing PHI from natural and environmental hazards, unauthorized intrusion, and other Threats. Physical Safeguards include the following sections of this Policy:

Section 4.02 - Facility Access Controls

raia will limit physical Access to electronic Information Systems and the facilities in which they are housed, while ensuring that properly authorized Access is allowed.

Section 4.03 - Workstation Use

raia will specify the proper Workstation functions to be performed, the manner in which those functions are to be performed, and the characteristics of the physical surroundings of Workstations that can Access PHI.

Section 4.04 - Workstation Security

raia will restrict right of entry to all Workstations that can Access PHI to authorized users.

Section 4.05 - Device and Media Controls

raia will govern the receipt and removal of hardware and Electronic Media that contain PHI into and out of a Facility, and the movement of these items within the Facility. The security procedure address: (a) the final disposition of PHI and/or the hardware or Electronic Media on which it is stored; (b) the removal of PHI from Electronic Media before the media are made available for re-use; and (c) the creation of retrievable, exact copies of PHI when needed, before movement of equipment occurs. The Security Official will assure that appropriate documentation is maintained to record the movement of hardware and Electronic Media and any person responsible therefor.

4.02 Facility Access Controls

raia will maintain Facility Access control procedures to limit physical Access to its PHI containing Information Systems and the Facility (or facilities) where they are housed, while ensuring that properly authorized Access is permitted.

a. Contingency Operations (Addressable)

When reasonable and practical, Workforce members and emergency personnel will be given Access to raia to assist in the restoration of lost data. For additional related procedures see: Data Backup Plan (Section 3.08(a)), Disaster Recovery Plan (Section 3.08 (b)), and Emergency Mode Operation Plan (Section 3.08 (c)). In addition, the following Physical Safeguards will be implemented to support Contingency Operations:

Fire Detectors: Heat-sensing

Fire Detectors: Flame-actuated

Automatic Dial-up Alarm

Fire Extinguishing Systems: Wet Pipe

Fire Extinguishing Systems: Dry Pipe

b. Facility Security (Addressable)

raia will safeguard its equipment from unauthorized physical Access, tampering and theft. The following Physical Safeguards will be implemented to support Facility perimeter security:

Guards (only on during business hours)

Lighting

Physical Locks

In addition, the following Physical Safeguards will be implemented to detect unauthorized intrusions to raia Facilities:

Alarms

Motion Detectors

c. Access Control and Validation Procedures (Addressable)

raia will control and validate a person’s Access to raia facilities using the following physical Access controls:

Access control (e.g., key locked system).

Visitors, upon arrival, must sign-in.

Visitors must be in raia of a Company Workforce member at all times when they are in an area where PHI is located.

d. Maintenance Records (Addressable)

raia will maintain a log of repairs and modifications to all physical security safeguards including hardware, locks, doors, and walls.

[45 CFR § 164.310(a)(2)]

4.03 Workstation Use

Workforce members will limit their Access and use of PHI- containing systems, applications, and/or Workstations in accordance with applicable Access control lists. In addition, Workforce members will be prohibited from attempting to bypass security protections and must follow all relevant security measures including: Workstation Security (Section 4.04), Facility Access Controls (Section 4.02), Authorization and/or Supervision (Section 3.04(a)), Access Control (Section 5.02), Audit Controls (Section 5.03), Person or Entity Authentication (Section 5.05), and Transmission Security (Section 5.06).

[45 CFR § 164.310(b)]

4.04 Workstation Security

raia will impose security procedures for all Workstations that have Access to PHI- containing systems or applications. See also Facility Access Controls (Section 4.02).

[45 CFR § 164.310(c)]

4.05 Device And Media Controls

raia maintains the following procedures governing the receipt and removal of hardware and Electronic Media that contain PHI, into and out of a Facility, and the movement of these items within the Facility.

raia will label Electronic Media containing PHI. Each device will have a number that corresponds to a technology asset tracker. This label will identify the device as containing PHI.

a. Disposal and Media Re-Use (Required)

raia will ensure proper sanitation of all Electronic Media containing PHI before it is transferred from the custody of its current custodian. The proper sanitization method depends on the type of media and the intended disposition of the media.

raia will not use ‘clearing data’ as a method for sanitizing media containing PHI. Clearing data (such as formatting or deleting information) removes information from storage media so that the information is unreadable. However, special utility software or techniques can be used to recover the cleared data.

raia will use the following method for sanitizing Electronic Media containing PHI: Overwriting disk drives, Low-Level formatting and “Zeroing out the drive.” CDs are shredded and destroyed.

raia will require vendors repairing or recovering data from any hard drive containing PHI to sign Business Associate Agreements. Once PHI is recovered or the hard drive is repaired, the original hard drive must be returned to the owner so that the owner can properly dispose of the hard drive.

b. Accountability (Addressable)

raia will maintain a record of the movements of hardware and electronic media and any person responsible therefor.

As needed, raia will create a retrievable, exact copy of the PHI (e.g., using a tape back-up, imaging the hard drive, or copying the PHI onto a network hard drive) to assure proper backup and storage.

[45 CFR § 164.310(d)]

5.0 Technical Safeguards

5.01 Overview

raia maintains technology procedures to protect and control Access to PHI. They are designed to guard against unauthorized Access to or alteration of PHI that is stored in an application or system or that is transmitted over a communications network. The Technical Safeguards include the following sections of this Policy.

Section 5.02 - Access Control

raia will maintain procedures to grant and allow Access to Electronic Information Systems that contain PHI to only those persons or software programs that have appropriate Access rights.

Section 5.03 - Audit Controls

raia will maintain procedural mechanisms and processes that record and examine activity in Information Systems that contain or use PHI.

Section 5.04 - Integrity

raia will maintain procedures to protect PHI from improper or unauthorized alteration or destruction.

Section 5.05 - Person or Entity Authentication

raia will verify that a person or entity seeking Access to PHI is the one claimed.

Section 5.06 - Transmission Security

raia will guard against unauthorized Access to PHI that is being transmitted over an electronic communications network.

5.02 Access Control

raia will restrict Access to applications or systems that contain PHI to those users that require Access to PHI to carry out raia’s administrative functions by the following administrative policies and procedures: Sanction Policy (Section 3.02(c)), Information System Activity Review (Section 3.02(d)), Authorization and/or Supervision (Section 3.04(a)), Termination Procedures (Section 3.04(c)), and Information Access Management (Section 3.05).

Access to electronic information systems that contain PHI are also restricted based on the user’s identity, and often also restricted based on the user’s role.

a. Unique User Identification (Required)

raia will require user Authentication for all Workforce members seeking Access to network applications or systems containing PHI. That Authentication will require a unique identifier (e.g., a log-in user ID) for each user. See also Person or Entity Authentication (Section 5.05).

Workforce members are instructed not to allow others to use their unique user ID and password, smart card, or Authentication information. Workforce members will make Anonymous users will not be permitted Access to PHI. All vendor-supplied passwords will be changed when new software or hardware is added to an electronic Information System containing PHI, or when new software or hardware has Access to such a system.

b. Emergency Access Procedure (Required)

raia will use the following Contingency Plan (Section 3.08) procedures for obtaining necessary PHI during an emergency:

Data Backup Plan (Section 3.08(a))

Disaster Recovery Plan (Section 3.08(b))

Emergency Mode Operation Plan (Section 3.08(c))

c. Automatic Logoff (Addressable)

Workforce members will log off and secure Workstations when not in use.

Facility Access Controls (Section 4.02) addresses additional Physical Safeguards that will be implemented to protect the security of Workstations.

d. Encryption and Decryption (Addressable)

As appropriate and consistent with guidelines established by the Security Official, PHI will be encrypted when stored and decrypted for use via the following methodology:

AES 256-excryption whenever possible. In cases where encryption is not available (i.e. mobile devices running on the Android operation system), AES 128-bit encryption will be used.

e. Technical Perimeter Control (Addressable)

The following Technical Safeguards will be used to protect PHI - containing systems from unauthorized Access from outside raia:

Quarterly Inspection of UTM Firewalls.

OpenDNS implemented.

raia will use the following measures to ensure that system perimeter controls have been effectively configured:

Source - This test measures the use of scanning with specific source ports through the firewall for enumeration.

Syn Flood - This tests the firewall’s ability to manage an ongoing series of SYN packets coming in.

ACK - This test is to discover the firewall’s ability to screen enumeration techniques using ACK packets.

NULL - This test is to discover the firewall’s ability to screen enumeration techniques using NULL packets.

Protocol - This test is to discover the firewall’s ability to screen packets of various protocols.

See also Protection from Malicious Software (Section 3.06(b)).

[45 CFR § 164.312(a)(2)]

5.03 Audit Controls

The following Audit controls will be implemented to identify suspect data Access, assess the effectiveness of raia’s security program, and respond to potential weaknesses:

raia will monitor:

Successful Logins

Failed Login Attempts

File Accessed

Security Incidents

Port Scans

To the extent feasible, all applications and systems containing PHI will record user identity, time, date of change and scope of PHI being accessed.

Audit logs will be maintained by the application and/or systems containing or having Access to PHI indefinitely.

See also Information System Activity Review (Section 3.02(d)), Log-in Monitoring (Section 3.06(c)) and Security Incident Procedures (Section 3.07).

[45 CFR § 164.312(b)]

5.04 Integrity

raia maintains procedures to authenticate PHI and to protect PHI from improper alteration or destruction.

To the extent feasible, raia will verify that PHI contained within all applications and systems has not been altered or destroyed in an unauthorized manner by using the following electronic mechanisms:

Checksums (Checksums belong to a class of hashing algorithms designed to detect errors or changes to data (e.g. Tripwire)).

Record Counts.

Data Edit Routines.

Parity Memory (The most common type of memory found on servers and workstations).

SAN Storage replication and Data Backup System replication

Uninterruptible Power Supply (UPS).

[45 CFR § 164.312(c)]

5.05 Person or Entity Authentication

raia will require specific ID and Password authentication to verify user identity of persons Accessing PHI-containing applications/or systems.

[45 CFR § 164.312(d)]

5.06 Transmission Security

raia maintains transmission security procedures to guard against unauthorized Access to PHI that is being transmitted over an electronic communications network.

raia will use at least one of the following methodologies to secure PHI when it is being transmitted over an open electronic network:

WPA-2 wireless network that is approved by the Security Official

Mobile hotspots that are owned by raia and have been approved for use to access PHI

Remote computer Access to PHI will only be provided to personnel who have demonstrated a need to Access PHI from off-site locations. (Authorization by the CEO)

raia will require users seeking remote Access to PHI containing systems or applications to use the following safeguards:

WPA-2 wireless network that is approved by the Security Official

Mobile hotspots that are owned by raia and have been approved for use to access PHI

a. Integrity Controls (Addressable)

In addition to the above under Section 5.06, see Mechanism to Authenticate PHI (Section 5.04) for raia’s integrity controls procedure.

b. Encryption (Addressable)

See above Section 5.06 for raia’s Transmission Encryption procedure.

[45 CFR § 164.312(e)]

6.0 Required Legal Documents

6.01 Overview

raia will enter in a Business Associate Agreement with all Covered Entities. raia will execute and retain copies of all necessary legal documentation as described in the following sections of this Policy:

Section 6.02 - Business Associate Contracts and Other Arrangements

raia may permit a Subcontractor to create, receive, maintain, or transmit PHI on its behalf, only if raia obtains a written contract or other documented arrangement with the Subcontractor as required by HIPAA. The contract or documented arrangement must provide satisfactory assurances that the Subcontractor will appropriately safeguard PHI.

Section 6.03 - Policies and Procedures

This Policy is intended to comprise of the policies and procedures to comply with the HIPAA Security Rule, which are reasonably designed and appropriate for the size and type of activities that relate to PHI. Any organizational or technological changes may require updates to this Policy.

Section 6.04 - Documentation

If an action, activity, or assessment is required by the HIPAA Security Rule to be documented, raia will also maintain a record of that action, activity, or assessment, in accordance with HIPAA requirements.

6.02 Business Associate Contracts and Other Arrangements

raia will obtain signed Business Associate Agreements that comply with HIPAA from all Subcontractors. In these Business Associate Agreements the Subcontractor must, among other things, agree to comply with the applicable requirements of the Security Rule.

A Subcontractor must sign a Business Associate Agreement. raia will not disclose PHI to a Subcontractor unless a Business Associate Agreement has been signed.

The Security Official will monitor the PHI that a Subcontractor must return to raia or destroy (or extend the protections of the Business Associate Agreement if the PHI is not returned or destroyed) upon termination of the Business Associate Agreement.

If the Security Official knows or suspects that a Subcontractor is violating the terms of its Business Associate Agreement, the Security Official will promptly notify the Privacy Official, and the Security Official and Privacy Official will cooperate to determine if a breach has occurred, if the breach can be cured, and to take any other actions that are indicated under HIPAA and otherwise appropriate.

[45 CFR § 164.308(b), 45 CFR § 164.314(a)]

6.03 Policies And Procedures

raia will implement reasonable and appropriate policies and procedures to comply with the HIPAA Security Rule, and such policies and procedures shall be set forth in this Policy. raia may change its policies and procedures at any time and shall document such changes in this Policy, in accordance with Section 6.04 of this Policy, and implement such changes in accordance with the Security Rule.

[45 CFR § 164.316(a)]

6.04 Documentation

raia will comply with the Security Rule requirements regarding documentation creation and retention.

a. Required Versus Addressable

The Security Rule categorizes implementation requirements as either “required” or “addressable.” When a standard includes required implementation specifications, raia shall implement those specifications. When a standard includes addressable implementation specifications, raia must assess whether each implementation specification is a reasonable and appropriate safeguard in its environment, and implement the implementation specification if reasonable and appropriate. If implementing the specification is not reasonable and appropriate, raia must document why it is not reasonable and appropriate to implement and implement an equivalent alternative measure if reasonable and appropriate.

a. Document Retention

raia will retain all documentation required by the HIPAA Security Rule for 6 years from the later of the date of its creation or the date when it was last in effect, whichever is later.

b. Availability

raia will make documentation available to those persons responsible for implementing the procedures, set forth in this Policy, to which the documentation pertains. See also Security Awareness and Training (Section 3.06).

c. Updates

raia will periodically review HIPAA security documentation, and update the documentation in response to environmental or operational changes affecting the security of the PHI, as needed.

[45 CFR § 164.316(b), 45 CFR § 164.306(d)(3)]

7.0 Complaints; Non-Retaliation

7.01 Complaints

The Security Official will be raia’s contact person for receiving and handling complaints about the policies and procedures set forth in this Policy, and raia’s compliance with this Policy or the requirements of the Security Rule, and for handling such complaints. The procedure for doing so shall be the complaints procedure outlined in the HIPAA Privacy Policy and Procedures Manual, which is maintained by the Privacy Official.

The Security Official will document complaints received and their resolutions in accordance with the Policy’s documentation procedures at Section 6.04.

7.02 No Intimidating or Retaliatory Acts

raia, in compliance with HIPAA, shall not and no employee shall intimidate, threaten, coerce, discriminate against, or take other retaliatory action against any individual or other person: (i) for the exercise of any right established, or for participation in any process provided for by the Security Rule, or (ii) for filing a complaint under HIPAA, or (iii) for testifying, assisting or participating in an investigation, compliance review, proceeding or hearing under HIPAA, or (iv) for opposing any act or practice made unlawful by HIPAA, provided the individual or person has a good faith belief that the practice opposed is unlawful, and the manner of opposition is reasonable and does not involve a disclosure of PHI in violation of the Privacy Rule. In addition, raia shall not require individuals to waive their rights under HIPAA to make a complaint to the Secretary of HHS.

If an employee or other person becomes aware of a violation of the foregoing prohibitions against intimidation, retaliation, etc. the employee or other person will promptly (but not later than 24 hours) notify the HIPAA Security Official, who shall cooperate with the HIPAA Privacy Official in resolving the matter in compliance with HIPAA and this Policy.

[45 CFR § 160.310, 45 CFR § 164.316]

8.0 Glossary

Access: The ability or the means necessary to read, write, modify, or communicate data/information or otherwise use any system resource.

Administrative Safeguards: Administrative actions and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect PHI and to manage the conduct of the Workforce in relation to the protection of that information.

Audit: Safeguards dealing with ensuring activity involving Access to and modification of sensitive or critical files is logged, monitored, and possible security violations investigated.

Authentication: The corroboration that a person is the one claimed.

Availability: The property that data or information is accessible and useable upon demand by an authorized person.

Business Associate: A person or entity that performs a function or activity regulated by HIPAA on behalf of a Covered Entity and involving PHI. Examples of such functions or activities are claims processing, legal, actuarial, accounting, consulting, data aggregation, management, administrative, accreditation, and financial services. A Business Associate may be a Covered Entity.

Confidentiality: The property that data or information is not made available or disclosed to unauthorized persons or processes.

Covered Entity: A health plan (including an employer plan, insurer, HMO, and government coverage such as Medicare); a health care provider (such as a doctor, hospital, or pharmacy) that electronically transmits any health information in connection with a transaction for which HHS has established an electronic data interchange standard; and a health care clearinghouse (an entity that translates electronic information between nonstandard and HIPAA standard transactions). The Covered Entities most likely to work with raia are health insurance plans and carriers and their business associates. HIPAA requires that raia enter into a written contract (Business Associate Agreement) with a Covered Entity and Subcontractors regarding PHI.

Disclosure: The release, transfer, provision of, access to, or divulging in any other manner of information outside the entity holding the information.

Encryption: The use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key.

Facility: The physical premises and the interior and exterior of a building(s).

HHS: The United States Department of Health and Human Services.

Information System: An interconnected set of information resources under the same direct management control that shares common functionality. A system normally includes hardware, software, information, data, applications, communications, and people.

Integrity: The property that data or information have not been altered or destroyed in an unauthorized manner.

Physical Safeguards: Physical measures, policies, and procedures to protect electronic Information Systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion.

Subcontractor: A person to whom a Business Associate delegates a function, activity or service, other than in the capacity of a member of the workforce of such Business Associate.

Technical Safeguards: The technology and the policy and procedures for its use that protect PHI and control access to it.

Threat: A potential force or situation that may exploit (accidentally or intentionally) a specific weakness in the safeguards protecting raia’s PHI.

Workforce: Individuals who would be considered part of raia’s workforce under the Privacy Rule, such as employees, volunteers, trainees, and other persons whose work performance is under the direct control of raia, whether or not they are paid by raia and who have Access to PHI.

Workstation: An electronic computing device, for example, a laptop or desktop computer, or any device that performs similar functions and Electronic Media stored in its immediate environment.

[45 CFR § 164.304, 45 CFR § 164.103]

9.0 Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

10.0 Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

11.0 Responsibility, Review, and Audit

This plan will be reviewed and tested on an annual basis. Ensuring that the plan reflects ongoing changes to resources is crucial. This task includes updating the plan and revising this document to reflect updates; testing the updates; and training personnel. Test results will be documented and signed off by raia management. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is tested, maintained and enforced by Richard Swier.

Last Updated: May 7, 2026

raia

Purpose and Scope

This Information Security Policy addresses the information security policy topics and requirements which maintain the security, confidentiality, integrity, and availability of raia applications, systems, infrastructure, and data. The topics and requirements called out in this policy should be continuously improved upon to maintain a secure information security posture.

From time to time, raia may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations. This policy is guided by security requirements specific to raia including compliance with applicable laws and regulations.

This policy applies to all raia assets utilized by personnel acting on behalf of raia or accessing its applications, infrastructure, systems or data. All personnel are required to read, accept and follow all raia policies and plans upon starting and at least annually.

Information Security Communication

Please contact r@raiaai.com if you have any questions about the raia information security program.

People Security

Background Check

All raia personnel are required to complete a background check. An authorized member of raia must review each background check in accordance with local laws.

Confidentiality

Prior to accessing sensitive information, personnel are required to sign an industry-standard confidentiality agreement protecting raia confidential information.

Security Awareness Training

raia has a security awareness training program in place to promote the understanding of security policies and procedures. All personnel are required to undergo training following initial employment and annually thereafter. Completion of the training program is logged by raia in Secureframe.

Secure Coding

raia promotes the understanding of secure coding to its engineers in order to improve the security and robustness of raia products.

Physical Security

Clear Desk

raia personnel are required to ensure that all sensitive information in hardcopy or electronic form is secure in their work area when it is unattended. This requirement extends to both remote and in-office work.

raia personnel must remove hardcopies of sensitive information from desks and lock the information in a drawer when desks are unoccupied and at the end of the work day. Keys used to access sensitive information must not be left at an unattended desk.

Clear Screen

raia employees and contractors must be aware of their surroundings at all times and ensure that no unauthorized individuals have access to see or hear sensitive information. All mobile and desktop devices must be locked when unoccupied. Session time-outs and lockouts are enforced through technical controls for all systems containing covered information.

All devices containing sensitive information, including mobile devices, shall be configured to automatically lock after a period of inactivity (e.g. screen saver).

Remote Work

Any raia issued devices used to access company applications, systems, infrastructure, or data must be used only by the authorized employee or contractor of such device.

Employees or contractors accessing the raia network or other cloud-based networks or tools are required to use HTTPS/TLS 1.2+ at a minimum to protect data-in-transit.

If you are in a public space, ensure your sight lines are blocked and do not have customer conversations or other confidential conversations. If someone is close to you, assume they can see and hear everything. Connecting directly to a public wireless network that doesn't employ, at minimum, WPA-2 or an equivalent wireless protocol is prohibited.

While working at home, employees and applicable contractors should be mindful when visitors (e.g. maintenance personnel) are at their residences, as visitors could become privy to sensitive information left up on computer screens.

System Access Security

raia adheres to the principle of least privilege, specifying that team members will be given access to only the information and resources necessary to perform their job functions as determined by management or a designee. Requests for escalation of privileges or changes to privileges and access permissions are documented and require approval by an authorized manager. System access is revoked immediately upon termination or resignation.

Account Audits

Audits of access and privileges to sensitive raia applications, infrastructure, systems, and data are performed regularly and reviewed by authorized personnel.

Password Security

Unique accounts and passwords are required for all users. Passwords must be kept confidential and not shared with anyone. Where possible, all user and system accounts must invoke password complexity requirements specified in the Access Control and Termination Policy. All accounts must use unique passwords not shared with any other accounts.

Rotation Requirements

If a password is suspected to be compromised, the password should be rotated immediately and the security team should be immediately notified.

Storing Passwords

Passwords must only be stored using a raia approved password manager. raia does not hard code passwords or embed credentials in static code.

Asset Security

raia maintains a Configuration and Asset Management Policy designed to track and set configuration standards to protect raia devices, networks, systems, and data. In compliance with such policy, raia may provide team members laptops or other devices to perform their job duties effectively.

Data Management

raia stores and disposes of sensitive data, in a manner that; reasonably safeguards the confidentiality of the data; protects against the unauthorized use or disclosure of the data; and renders the data secure or appropriately destroyed. Data entered into raia applications must be validated where possible to ensure quality of information processed and to mitigate the impacts of web-based attacks on the systems.

Data Classification

raia defines the handling and classification of data in the Data Classification Policy.

Data Retention and Disposal Policy

The time periods for which raia must retain customer data depends on the purpose for which it is used. raia retains customer data as long as an account is active, as needed to provide services to the customer, or in accordance with the agreement(s) between raia and the customer. An exemption to this policy would include if raia is required by law to dispose of data earlier or keep data longer. raia may retain and use customer data to comply with its legal obligations, resolve disputes, and enforce agreements.

Except as otherwise set forth in the raia policies, raia also disposes of customer data when requested by customers.

raia maintains a sanitization process that is designed to prevent sensitive data from being exposed to unauthorized individuals. raia hosting and service providers are responsible for ensuring the removal of data from disks allocated to raia use before they are repurposed or destroyed.

Change and Development Management

To protect against unauthorized changes and the introduction of malicious code, raia maintains a Change Management Policy with change management procedures that address the types of changes, required documentation, required review and/or approvals, and emergency changes.

Changes to raia production infrastructure, systems, and applications must be documented, tested, and approved before deployment.

Vulnerability and Patch Management

raia uses a proactive vulnerability and patch management process that prioritizes and implements patches based on classification. Such classification may include whether the severity is security-related or based on other additional factors. raia schedules third party penetration tests and/or performs internal assessments at least annually.

If you believe you have discovered a vulnerability, please email r@raiaai.com and raia will aim to address the vulnerability, if confirmed, as soon as possible.

Environment Separation

As necessary, raia maintains requirements and controls for the separation of development and production environments.

Source Code

raia controlled directories or repositories containing source code are secured from unauthorized access.

Logging and Monitoring

raia collects & monitors audit logs and alerts on key events stemming from production systems, applications, databases, servers, message queues, load balancers, and critical services, as well as IAM user and admin activities. raia manages logging solution(s) and/or SIEM tool(s) to collect event information of the aforementioned systems and activities. raia implements filters, parameters, and alarms to trigger alerts on logging events that deviate from established system and activity baselines. Logs are securely stored and archived for a minimum of 1 year to assist with potential forensic efforts.

Logs are made available to relevant team members for troubleshooting, auditing, and capacity planning activities. System and user activity logs may be utilized to assess the causes of incidents and problems. raia utilizes access control to prevent unauthorized access, deletion, or tampering of logging facilities and log information.

When events and alerts are generated from monitoring solutions and mechanisms, raia correlates those events and alerts across all sources to identify root causes and formally declare incidents, as necessary, in accordance with the Security Incident Response Policy and Change Management Policy.

Additionally, raia utilizes threat detection solution(s) to actively monitor and alert on network and application-based threats.

Business Continuity and Disaster Recovery

raia maintains a plan for continuous business operations if facilities, infrastructure or systems fail. The plan is tested, reviewed and updated at least annually.

Backup Policy

Backups are performed according to appropriate backup schedules to ensure critical systems, records, and configurations can be recovered in the event of a disaster or media failure.

Security Incident Response

raia maintains a plan that defines responsibilities, detection, and corrective actions during a security incident. The plan will be executed following the discovery of an incident such as system compromise, or unintended/unauthorized acquisition, access, use or release of non-public information. The plan is tested, reviewed and updated at least annually.

raia utilizes various monitoring and surveillance tools to detect security threats and incidents. Early detection and response can mitigate damages and minimize further risk to raia.

A message should be sent to r@raiaai.com if you believe there may be a security incident or threat.

Risk Management

raia requires a risk assessment to be performed at least annually. For risks identified during the process, raia must classify the risks and develop action plans to mitigate discovered risks.

Vendor Management

raia requires a vendor security assessment before third party products or services are used confirming the provider can maintain appropriate security and privacy controls. The review may include gathering applicable compliance audits (SOC 1, SOC 2, PCI DSS, HITRUST, ISO 27001, etc.) or other security compliance evidence. Agreements will be updated and amended as necessary when business, laws, and regulatory requirements change.

Privacy

Personal Data

raia personnel must treat personal data with appropriate security and handling and accommodate data subject requests, as required by applicable laws and regulations. No unauthorized personnel should have access to personal data.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is maintained by Richard Swier.

This document was last updated on May 7, 2026.

raia

Internal Control Policy

Purpose and Scope

This Internal Control Policy guides raia regarding the maintenance of an internal control system in order to safeguard the raia's assets against loss, promote operational efficiency, and encourage adherence to prescribed managerial policies.

From time to time, raia may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations. This policy is guided by security requirements specific to raia including applicable laws and regulations.

This policy applies to all raia assets utilized by personnel acting on behalf of raia or accessing its applications, infrastructure, systems, or data. All personnel are required to read, accept, and follow all raia policies and plans.

Internal Control

Control Environment

raia senior management recognizes that a proper control environment provides the discipline and structure to help raia achieve its objectives. raia manages and maintains its internal controls through the use of the Secureframe platform.

Responsibility

raia senior management is responsible for ensuring that an adequate and effective internal control system exists at raia and that dedicated personnel are necessary for monitoring the performance of the internal control system. Senior management must establish and define responsible parties with accountability for overseeing and maintaining internal control processes and procedures. These lines of accountability should be reviewed annually to ensure that performance measures are being met. Corrective measures or changes in responsibility should be implemented as needed.

Annual Review

Internal control processes and procedures should be reviewed by raia senior management annually. Senior management may choose to sample a number of controls for review per year. Any outdated or non-operating procedures should be updated or removed. New controls should be implemented where appropriate.

Identified Deficiencies

Identified control failures or deficiencies and proposed corrective action plans for newly identified issues must be addressed and communicated to management.

Evaluation of Internal Controls

Internal control objectives are identified by relevance to the company, department, business line, or product.

As part of the evaluation process, a review of pertinent policies, procedures, and documentation will be completed to verify that applicable internal controls are operating effectively, and in line with business objectives.

A member of raia management or a designee will document the review of internal control policies and procedures and sign off on the review. Findings will be shared, as appropriate.

Identified issues are assessed to determine the impact to internal control. If necessary, corrective action plans are developed, tracked via documentation, and monitored until implementation.

Changes to Internal Controls

If a corrective action or change is required, raia management must assess the changes that could significantly impact the system of internal control including:

• External environment,
• Current business model,
• Leadership, and
• Business relationships (vendors, business partners, and other third-parties)

All changes must be approved by management before implementation. If the change is related to security of network and IT resources, the change must be approved and documented in accordance with documented change management procedures.

Changes to internal control activities must be communicated to all affected users in a timely manner.

Communication with External Third Parties

raia will communicate with external parties regarding the functioning of internal control (i.e. material changes to internal controls that affect nondisclosure agreement or contractual confidentiality and privacy provisions.).

raia will conduct an assessment to determine whether changes need to be communicated to and affirmed by the customer, partner, vendor, or other third parties. The manner in which the change is communicated must be in line with the significance of the change.

Communications with legal or regulatory implications must be reviewed and approved by management.

Exceptions

raia business needs, local situations, laws, and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any personnel who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

raia

Network Security Policy

Purpose and Scope

The purpose of this document is to define basic rules and requirements for network security and ensure the protection of information within and across networks and supporting information processing facilities.

This document applies to the security of all services, architecture, software and systems that make up raia's product/service, including our AI agent SaaS platform and proprietary framework.

Users of this document are all employees and applicable contractors who work on network engineering, security, and maintenance at raia.

Network Controls

raia manages, controls, and secures its networks, the connected systems, applications, and data-in-transit to safeguard against internal and external threats. This includes our cloud infrastructure hosted on Google Cloud.

Firewalls & Threat Defense

raia must utilize network firewalls, web application firewalls, and/or equivalent mechanisms to safeguard applicable internet connections, internal network zones, and applications from threats. raia configures appropriate firewall alerts and alarms for timely response and investigation. This also applies to applicable wireless networks.

raia ensures networking ports and protocols are restricted based on the principle of least functionality. Ports and network routes should only be open when there is proper business justification. Firewall configurations and rulesets are maintained. Firewall rules are implemented to minimize exposure to external threats. Significant changes to network services and configurations should be tracked in accordance with the Change Management Policy.

As an additional layer of defense, raia utilizes monitoring solutions, including Secureframe for agent-based device monitoring, to detect and alert on network-based intrusions and/or threats.

Network Diagramming

Richard Swier maintains network and data flow diagrams. Diagrams are reviewed and updated when significant network infrastructure changes occur.

Network Access Control

In addition to the Network Security Policy, raia establishes, documents, and reviews the Access Control and Termination Policy based on business and security requirements. This policy also encompasses network access control.

raia segregates networks based on the required groups of information services, users, and systems.

raia utilizes firewall configurations to restrict connections between untrusted networks and trusted networks.

Additionally, raia may utilize security groups and network access control lists (NACLs) to improve network security for individual virtual machines within our Google Cloud environment.

Network Engineering

raia implements security functions in a layered approach, minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.

raia utilizes a defense-in-depth (DiD) architecture to protect the confidentiality, integrity, and availability of information systems and data, i.e. placing information systems that contain sensitive data in an internal network zone, segregated from the DMZ and other untrusted networks.

raia synchronizes clocks of all applicable information systems to the same time protocol to enforce consistent and accurate timestamping.

Network Service Level Agreements (SLAs)

Security mechanisms, service levels and management requirements of all network services should be identified and included in network services agreements, whether these services are provided in-house or outsourced to vendors such as Google Cloud.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any personnel who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

raia

Purpose

The performance evaluation process provides a means for discussing, planning and reviewing the performance of each team member. This provides both the employee and the department manager with the opportunity to discuss job tasks, identify and correct weaknesses, encourage and recognize strengths, and discuss methods for improving performance.

Performance evaluations may influence salaries, job responsibilities, promotions and transfers. It is critical that supervisors are objective in conducting performance reviews and in assigning overall performance ratings.

Eligibility

All employees who have been employed by raia for at least 1 year undergo an annual performance review. Managers are strongly encouraged to conduct reviews on a more frequent basis.

Performance Review Schedule

Performance evaluations are conducted annually with specific dates announced by Management. Each manager is responsible for the timely and equitable assessment of the performance and contribution of their team members. All performance reviews should be documented and retain to track an individual's performance over time.

Salary Increases

A performance evaluation does not always result in an automatic salary increase. The employee’s overall performance and salary level relative to position responsibilities must be evaluated to determine whether a salary increase is warranted.

Processes

Management will establish the format and timing of all review processes. The reviews may change from year to year and from person to person. The completed evaluations will be retained and documented.

Managers may not discuss any proposed action with the employee until all written approvals are obtained.

Management will review all salary increase/adjustment requests to ensure compliance with company policy and that they fall within the provided guidelines.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any personnel who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

raia

Purpose and Scope

The Physical Security Policy specifies the requirements for physically protecting assets and their data via physical controls and safeguards. Physical security is the first line of defense in information security, and without physical protections, virtual protections offer minimal security for assets and data. raia maintains reasonable steps to ensure that its facilities, information systems, and data are accessed only by authorized personnel or authorized third party visitors to prevent unauthorized access, damage, theft, and interference. All physical security requirements are applicable to both remote and in-office work. Key aspects of physical security include: perimeter and border security, entry controls, visitor management, restricted areas, equipment protection and maintenance, awareness and training, and risk management.

Perimeter and Border Security

raia facilities should be secured via external locked doors. raia facilities should be monitored via personnel, security cameras, and/or other mechanisms to detect potential security threats and respond to alerts.

Entry Controls

raia requires employees and applicable contractors to utilize access cards/keys to unlock external doors throughout all business hours. For facilities that have a security desk at the point of initial external access, external doors can be left unlocked as long as 1) employees and/or contractors authenticate prior to internal access via key/badge and 2) visitors are required to sign-in at the security desk prior to internal admittance.

Visitor Management

All visitors must sign-in with security prior to being allowed in internal office areas. Upon sign-in, the following visitor-specific information should be collected:

• Visitor name
• Visitor organization name (if applicable)
• Government-issued identification card information

Upon exit, the badge/nametag should be collected and the hr/min/sec timestamp for visitor exit should be captured. Visitor logs should be stored for at least 90 days via securely stored paper or digital records. Visitors that are unescorted should not have the ability to logically access restricted areas unless pre-authorization has been given by the approving manager. Visitors should receive a temporary badge or nametag - badge/nametag should be marked in a way that identifies them as a visitor. Any non-escorted or unauthorized visitors should be reported to the security team immediately.

Restricted Areas

Only authorized personnel shall be allowed entry into restricted areas. Restricted areas may include:

• Personal, confined offices
• Network closets
• Power & utilities closets
• Server rooms (as applicable)

Restricted areas must be secured via access badges/keys or security personnel.

Equipment

The following types of protection and monitoring equipment should be maintained at all times:

• Power utilities (e.g. generators, UPS)
• HVAC systems, including environmental sensors (thermometers and humidity sensors)
• Fire suppression systems
• Network, power, and telecommunications cabling
• On-premise servers and desktops (as applicable)
• Physical data backups

raia must securely store/protect the aforementioned equipment/assets from physical threats via proper access controls.

raia should maintain awareness of necessary maintenance schedules for the aforementioned equipment/assets. Maintenance should occur accordingly to prevent the failure of any of the aforementioned assets. Any third party/maintenance company that has access to a raia facility (e.g. night cleaning company) must receive security clearance from management and must follow all applicable parts of the security policies. Maintenance to and external movement of physical security components should be documented and tracked accordingly.

Risk Management

raia includes physical security within annual risk assessment scope.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any personnel who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

Purpose and Scope

In its everyday business operations raia makes use of a variety of personal data, including data about:

• Current, past and prospective employees
• Customers
• Users of and visitors to its websites
• Subscribers
• Other stakeholders

In collecting and using this data, the organization is subject to a variety of legislation controlling how such activities may be carried out and the safeguards that must be put in place to protect it.

The purpose of this policy is to set out the relevant legislation and to describe the steps raia is taking to ensure that it complies with it. This control applies to all systems, people and processes that constitute the organization’s information systems, including board members, directors, employees, suppliers and other third parties who have access to raia systems.

Privacy and data protection policy

Applicable privacy legislation

The list below shows the main items of privacy legislation that apply to the countries (or groups of countries) and states within which raia operates.

• Argentina - Personal Data Protection Law (PDPL)
• Australia - Privacy Act
• Australia - Privacy and Personal Information Protection Act
• Brazil - General Data Protection Law (LGPD)
• Canada - Personal Information Protection and Electronic Documents Act (PIPEDA)
• Canada – Quebec - Act respecting the protection of personal information in the private sector
• European Union - General Data Protection Regulation (GDPR)
• Singapore - Personal Data Protection Act
• United Kingdom - UK GDPR Data Protection Act
• USA – California - California Consumer Privacy Act (CCPA)

raia has a legal obligation to comply with the provisions of this legislation at all times. Whilst there will be variations in these provisions, this policy establishes the key principles that are commonly required to be observed in such legislation.

Significant fines may be applicable if a breach is deemed to have occurred under the relevant privacy legislation, which is designed to protect the personal data of citizens of the country (or state, region or countries) involved. It is raia’s policy to ensure that our compliance with applicable legislation is clear and demonstrable at all times.

Definitions

The definitions used within privacy legislation vary and it is not appropriate to reproduce them all here. However, the common terms used within this policy are as follows:

Personal data: Any information that (a) can be used to identify the personal data principal to whom such information relates, or (b) is or might be directly or indirectly linked to a personal data principal.

Personal data principal: Natural person to whom the personal data relates. This term is also referred to as data subject.

Processing of personal data: Operation or set of operations performed upon personal data. Examples of processing operations of personal data include, but are not limited to, the collection, storage, alteration, retrieval, consultation, disclosure, anonymization, pseudonymization, dissemination or otherwise making available, deletion or destruction of personal data.

Data Controller: Privacy stakeholder (or privacy stakeholders) that determines the purposes and means for processing personal data other than natural persons who use data for personal purposes.

Data Processor: Privacy stakeholder that processes personal data on behalf of and in accordance with the instructions of a data controller.

Principles relating to processing of personal data

There are a number of fundamental principles upon which most privacy legislation is based. These are summarized as follows:

• Lawfulness, fairness and transparency - personal data shall be processed lawfully, fairly and in a transparent manner in relation to the personal data principal
• Purpose limitation – personal data shall be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes
• Data minimization – the personal data collected and stored shall be adequate, relevant and limited to what is necessary in relation to the purposes for which it is processed
• Accuracy – personal data shall be accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that is inaccurate, having regard to the purposes for which it is processed, is erased or rectified without delay
• Storage limitation – personal data shall be kept in a form which permits identification of personal data principals for no longer than is necessary for the purposes for which the personal data is processed
• Integrity and confidentiality – personal data shall be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organizational measures

Processing of special categories of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited. Exception to this restriction is only applicable by lawful exceptions including but not limited to processing necessary to: reasons of public interest, purposes of preventive medicine, and defense or exercise of a legal claim.

raia will ensure that it complies with all these principles both within processing and as part of the introduction of new methods of system processing such as new IT systems.

Rights of the individual

The personal data principal also has rights with regard to their personal data. These will generally consist of:

• The right to be informed
• The right of access
• The right to rectification
• The right to erasure
• The right to restrict processing
• The right to data portability
• The right to object
• Rights in relation to automated decision making and profiling.

Each of these rights are supported by appropriate procedures within raia that allow the required action to be taken within the timescales stated in the applicable privacy legislation.

These timescales are shown in the list below:

• The right to be informed - When data is collected (if supplied by personal data principal) or within one month (if not supplied by personal data principal)
• The right of access - One month
• The right to rectification - One month
• The right to erasure - Without undue delay
• The right to restrict processing - Without undue delay
• The right to data portability - One month
• The right to object - On receipt of objection
• Rights in relation to automated decision making and profiling - Not specified

If raia does not take action on the request of the personal data principals, raia shall inform the personal data principal at the latest within one month of receipt of the request of the reasons for not taking action.

In cases where requests from a personal data principal are unfounded or excessive, raia may either: charge a reasonable fee taking into account the administrative costs of providing the information/communication/taking the action requested; or refuse to act on the request.

Furthermore, raia may request additional information necessary to confirm the identity of the personal data principal making the request. The information provided to personal data principals shall be comprehensible and in a clearly legible manner with an overview of the intended processing.

Moreover, raia shall take reasonable steps to inform relevant data controllers, data processors, and recipients (as applicable) of request of rectification/erasure/restriction of processing from the data principal, unless this proves impossible or involves disproportionate effort.

Lawfulness of processing

Depending on the legislation involved, there may be a number of alternative ways in which the lawfulness of a specific case of processing of personal data may be established. It is raia policy to identify the appropriate basis for processing and to document it, in accordance with the applicable legislation. The main options are described in brief in the following sections.

Consent

Where appropriate, raia will obtain consent from a personal data principal to collect and process their data. In cases of children being below the age specified in applicable legislation, parental consent will be obtained. Transparent information about our usage of their personal data will be provided to personal data principals at the time that consent is obtained and their rights regarding their data explained, such as the right to withdraw consent. This information will be provided in an accessible form, written in clear language and free of charge.

If the personal data is not obtained directly from the personal data principal, then this information will be provided to the personal data principal within a reasonable period after the data is obtained and definitely within one month.

Performance of a contract

Where the personal data collected and processed is required to fulfill a contract with the personal data principal, consent is not required. This will often be the case where the contract cannot be completed without the personal data in question, for example, a delivery cannot be made without an address.

Legal obligation

If the personal data is required to be collected and processed in order to comply with applicable law, then consent is not required. This may be the case for some data related to employment and taxation for example, and for many areas addressed by the public sector. For example, processing of personal data relating to criminal convictions and offenses or related security measures.

Vital interests of the personal data principal

In a case where the personal data is required to protect the vital interests of the personal data principal or of another natural person, then this may be used as the lawful basis of the processing. raia will retain reasonable, documented evidence that this is the case, whenever this reason is used as the lawful basis of the processing of personal data. As an example, this may be used in aspects of social care, particularly in the public sector.

Task carried out in the public interest

Where raia needs to perform a task that it believes is in the public interest or as part of an official duty then the personal data principal’s consent will not be requested. The assessment of the public interest or official duty will be documented and made available as evidence where required.

Legitimate interests

If the processing of specific personal data is in the legitimate interests of raia and is judged not to affect the rights and freedoms of the personal data principal in a significant way, then this may be defined as the lawful reason for the processing. Again, the reasoning behind this view will be documented.

Privacy by design

raia has adopted the principle of privacy by design and will ensure that the definition and planning of all new or significantly changed systems that collect, or process personal data will be subject to due consideration of privacy issues, including the completion of one or more privacy impact assessments.

The privacy impact assessment will include:

• Consideration of how as well as what types of personal data will be processed and for what purposes
• Assessment of whether the proposed processing of personal data is both necessary and proportionate to the purpose(s)
• Assessment of the risks to individuals in processing personal data
• What controls are necessary to address the identified risks and demonstrate compliance with applicable legislation

Use of techniques such as data minimization/pseudonymization/encryption will be considered where applicable and appropriate, including at the end of processing, and the mechanisms used to achieve them will be documented.

Where a data protection impact assessment indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk, raia shall consult the supervisory authority prior to processing.

Contracts involving the processing of personal data

raia will ensure that all relationships it enters that involve the processing of personal data are subject to a documented contract that includes the specific information and terms required by the applicable legislation.

International transfers of personal data

Transfers of personal data between countries will be carefully reviewed prior to the transfer taking place to ensure that they fall within the limits imposed by the applicable legislation. This depends partly on the relevant authority’s judgment (for example in the case of the GDPR, the European Commission) as to the adequacy of the safeguards for personal data applicable in the receiving country and this may change over time.

Where an adequacy decision (or similar statement) does not exist for a destination country, an appropriate safeguard such as standard contractual clauses will be used, or a relevant exception identified as permitted under the applicable legislation.

Intra-group international data transfers will be subject to legally binding agreements referred to as Binding Corporate Rules (BCR) which provide enforceable rights for personal data principals.

Data protection officer

A defined role of Data Protection Officer (DPO) is generally required under privacy legislation if an organization is a public authority, if it performs large scale monitoring or if it processes particularly sensitive types of data on a large scale. The DPO is required to have an appropriate level of knowledge and can either be an in-house resource or outsourced to an appropriate service provider.

Based on these criteria, raia does not require a Data Protection Officer to be appointed.

Breach notification

It is raia's policy to be fair and proportionate when considering the actions to be taken to inform affected parties regarding breaches of personal data. In line with the applicable legislation, where a breach is known to have occurred which is likely to result in a risk to the rights and freedoms of individuals, the relevant supervisory authority will be informed within the specified timeframe.

GDPR Breach Notification (Article 33):

Where a personal data breach affects EU/EEA data subjects, raia must notify the relevant supervisory authority within 72 hours of becoming aware of the breach. If notification is not achievable within 72 hours, the reasons for the delay must be documented and provided alongside the notification. The notification must describe the nature of the breach, approximate number of data subjects affected, likely consequences, and measures taken or proposed to mitigate the breach.

Communication to Data Subjects (Article 34):

Where the breach is likely to result in a high risk to the rights and freedoms of affected individuals, raia must communicate the breach to those individuals without undue delay, in clear and plain language.

Processor Obligations:

Where raia acts as a data processor, raia must notify the data controller without undue delay after becoming aware of a personal data breach, to enable the controller to fulfill its own 72-hour notification obligation.

All breach notification activities will be managed in accordance with the raia Security Incident Response Plan, which sets out the overall process of handling information security incidents, including the Regulatory Notification Requirements section and Notification Decision Matrix.

Under privacy legislation, the relevant authority may have the right to impose a range of fines. Under the GDPR, fines for breach notification failures may reach up to EUR 10 million or 2% of annual worldwide turnover (whichever is greater), and fines for violations of data processing principles may reach up to EUR 20 million or 4% of annual worldwide turnover (whichever is greater).

Data Protection Impact Assessments (DPIA)

raia shall conduct a Data Protection Impact Assessment prior to any processing that is likely to result in a high risk to the rights and freedoms of natural persons, including but not limited to:

• Systematic and extensive evaluation of personal aspects relating to natural persons based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the natural person;
• Processing on a large scale of special categories of data or personal data relating to criminal convictions and offenses;
• Systematic monitoring of a publicly accessible area on a large scale.

The DPIA shall contain at minimum: a systematic description of the envisaged processing operations and purposes; an assessment of the necessity and proportionality of the processing; an assessment of the risks to the rights and freedoms of data subjects; and the measures envisaged to address those risks.

Where a DPIA indicates that the processing would result in a high risk in the absence of measures taken to mitigate the risk, raia shall consult the relevant supervisory authority prior to processing.

Records of Processing Activities

In accordance with Article 30 of the GDPR, raia maintains records of processing activities under its responsibility. These records include:

• The name and contact details of raia and its designated privacy contact;
• The purposes of the processing;
• A description of the categories of data subjects and categories of personal data;
• The categories of recipients to whom personal data has been or will be disclosed;
• Where applicable, transfers of personal data to a third country, including identification of that country and the transfer safeguards in place;
• Where possible, the envisaged time limits for erasure of the different categories of data;
• Where possible, a general description of the technical and organizational security measures in place.

These records are maintained electronically and made available to the supervisory authority upon request.

Addressing compliance to applicable privacy legislation

The following actions are undertaken to ensure that raia complies at all times with the accountability principle of privacy legislation within the countries in which it operates:

• The legal basis for processing personal data is clear and unambiguous
• A Data Protection Officer is appointed with specific responsibility for data protection in the organization (if required)
• All staff involved in handling personal data understand their responsibilities for following good data protection practice
• Training in data protection has been provided to all staff
• Rules regarding consent are followed
• Routes are available to personal data principals wishing to exercise their rights regarding personal data and such inquiries are handled effectively
• Regular reviews of procedures involving personal data are carried out
• Privacy by design is adopted for all new or changed systems and processes

The following documentation of processing activities is recorded:

• Organization name and relevant details
• Purposes of the personal data processing
• Categories of individuals and personal data processed
• Categories of personal data recipients
• Agreements and mechanisms for transfers of personal data to other countries including details of controls in place
• Personal data retention schedules
• Relevant technical and organizational controls in place

These actions are reviewed on a regular basis as part of the management process concerned with privacy and data protection.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any personnel who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is maintained by Richard Swier.

This document was last updated on May 7, 2026.

Purpose and Scope

This Processing Integrity Policy defines standards, procedures, and processes for data and system processing that is complete, accurate, and authorized to meet raia’s objectives. raia integrates with many different platforms and technologies as a software as a service (SaaS). It is critical that data is processed in a complete, accurate, and authorized fashion.

Roles & Responsibilities

This policy is guided by security requirements specific to raia, including applicable laws and regulations.

This policy applies to all raia personnel acting on behalf of raia or accessing its applications, infrastructure, systems and/or data. All personnel are required to read, accept, and follow all of raia policies and plans.

Additionally, this policy applies to all types of data that pass through raia. For more information on types of data within the raia environment, please refer to raia’s Data Classification Policy.

raia is the owner of all raia-issued hardware such as employee workstations and electronic systems and of the data stored in them or transmitted from them. Thus, any raia employees, contractors, clients, or anyone using raia hardware or software is required to follow and comply with this Processing Integrity Policy.

Processing Integrity Objectives

As raia integrates with many different softwares and technologies, raia aims to collect and maintain data accurately and completely. These objectives apply to all data defined and documented in the Data Classification Policy. raia has identified the following objectives around the protection and processing of data:

• raia will protect all data that enters, leaves, and/or is stored in the raia environment.
• This data will be encrypted at rest and in transit.
• Only authorized personnel will have access to this data.
• raia will communicate to and train all end users on the protection and security of relevant data. Training is done with an onboarding guide and support regarding control implementation.
• raia will review the Data Classification policy on an annual basis to ensure that security and handling policies and procedures for protecting and classifying sensitive data are up to date and accessible for all in-scope personnel.

In case of any processing errors, raia has identified and created the following policies and procedures to prevent, detect, and correct any processing errors.

raia automatically syncs to integrated technologies and platforms daily or manually at any point by the user and any processing errors will be captured during the daily automatic sync and immediately when the user triggers a manual sync.

If a processing error is found, the error will be reported by the user or internal personnel that monitor the processing errors, and a bug ticket will be created for the error in the internal ticketing tool (Confluence). If a user finds the error, they can report it via the internal feedback feature in raia or communicate the error to their Customer Success Manager who will create the ticket in the internal ticketing tool. If the user reports the error via the internal feedback feature, a support ticket will be created followed by a ticket in the internal ticketing tool to monitor and assess the issue.

Once a bug ticket has been created, it will be reviewed by the on-call engineer. The engineer will provide feedback on the issue and determine a response time for resolving.

If the bug is remediated, the engineer will notify the Customer Success Manager that the bug has been fixed and the ticket will be closed.

User account reviews are performed quarterly to control personnel access to client data. Richard Swier verifies appropriate permissions quarterly by reviewing the following systems: Google Cloud, Google Workspace, GitHub, OpenAI, Stripe, n8n. Any necessary changes are documented in a change ticket.

Audit log reviews are performed quarterly to detect any anomalies relevant to access to client data. Richard Swier reviews audit logs and notifications quarterly relevant to admin access and change activity in the following systems: Google Cloud, Google Workspace, GitHub, OpenAI, Stripe, n8n. Any potential anomalies detected follow the incident response process.

System Inputs

raia requires that system inputs contain the appropriate characteristics to ensure inputs and their data are properly entered into the system to maintain processing integrity. raia defines and requires the following characteristics for systems inputs:

• Complete
• Accurate
• Up-to-date
• Relevant
• Timely
• Reviewed and/or validated

Additionally, raia defines the following types of data inputs within the system:

• Manual information inputs including:
• Company information
• Any free form text box and additional details
• Automated data inputs from integrations (e.g., Google Workspace, Stripe, OpenAI)

raia has implemented the following system input controls to ensure that data inputs are properly configured to result in complete and accurate data:

• Edit checks for system inputs
• Input validations for system inputs
• Logging and monitoring of system inputs
• Access controls that ensure appropriate and authorized personnel are inputting data

System Processing

raia requires complete, accurate, and authorized system processing in order for the system and platform to function properly to provide raia’s intended service. In order to complete the system processing necessary for maintaining the integrity of the system’s data, raia must complete the following:

• System integrations must be configured properly and synced regularly in order for the correct data to be pulled and processed by raia.
• Integrations are fully tested for functionality prior to being released to users.
• Input criteria and remediation for manual uploads, in-platform tasks, and integration connections are provided to users to ensure the maintenance of processing integrity.
• Daily system syncs and the ability to sync at any time to ensure processing data is complete, accurate, and up to date.
• Logging and monitoring of integrations and data flows, including failed sync attempts or processes.
• Data pulled into raia via integrations are immediately stored within a database and cannot be changed by end users. raia provides users with in-platform functions to update, reorganize, and perform tasks against the data but cannot impact the integrity of the data.
• In the event of a processing error, Bugs can be reported by end users through the UI or by internal user through a shortcut ticket, are tracked to resolution, and follow the raia change management process.

System Outputs

raia requires that system and processing outputs are complete, accurate, and timely to ensure that raia personnel and customers are receiving complete and accurate data. raia has implemented the following system output controls to ensure that outputs are properly generated from the system to result in complete and accurate data:

• Access to the database where ingested data is stored is restricted only to specific raia administrators. Users do not have the ability to make direct changes to data once stored in the system and displayed. Changes to data are performed via specific functions within the application where any changes are logged.
• Data storage solutions containing sensitive customer data are encrypted at rest.
• Access controls to the raia ensure that customers control who has access to their data and information.
• Data Export functionality from the system is non-configurable, designed completely and accurately, and changes follow the change management process.
• raia exports are sampled and tested before being pushed to production.
• Logging and monitoring of system outputs and exports.

System Storage

raia requires that system and processing inputs, items in processing, and outputs are stored completely, accurately, and timely in accordance with system specifications required to protect all relevant data. raia has implemented the following system storage controls to ensure that data storage keeps raia and all relevant stakeholders data complete, accurate, and in a timely fashion:

• Logging and monitoring of system inputs, outputs, and storage.
• Successful integrations and/or any integration errors are logged, monitored and stored.
• Creation and maintenance of system storage logs and records.
• Full backups or versioning of the production environment are performed daily and retained in accordance with the Business Continuity and Disaster Recovery Policy (minimum 30 days for database backups).
• System logs and records are backed up to raia databases for at least 90 days.
• raia databases are protected from unauthorized use or actions. Databases are protected with database access controls providing access to only those that need it.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any personnel who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is maintained by Richard Swier.

This document was last updated on May 7, 2026.

raia

Risk Assessment and Treatment Policy

Purpose and Scope

This Risk Assessment Policy guides raia in performing risk assessments to account for threats, vulnerabilities, likelihood, and impact to raia assets, team members, customers, vendors, suppliers, and partners based upon the raia services considering security, availability, integrity, and confidentiality needs.

From time to time, raia may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations. This policy is guided by security requirements specific to raia including applicable laws and regulations.

This policy applies to all raia assets utilized by personnel acting on behalf of raia or accessing its applications, infrastructure, systems, or data. All personnel are required to read, accept, and follow all raia policies and plans.

Risk Assessment Framework

raia conducts assessments of risk, which includes the likelihood and impact of risk from the unauthorized access, use, disclosure, disruption, modification and/or destruction of raia systems, applications, infrastructure, and data pertaining to raia's environment.

The risk assessment process is coordinated by Richard Swier, which includes the identification and evaluation of assets, threats, and vulnerabilities. Assets should be identified by respective asset owners, and the assessment of threats as well as the likelihood and criticality of potential vulnerability exploitation, should be performed by respective risk owners.

A risk assessment may include a review of:

• internal controls including policies, procedures, business processes, and technical security safeguards
• human resource practices related to hiring, termination, and discipline procedures
• facility controls
• exposure to theft
• systems and applications used to collect, store, process or transmit confidential data
• fraud

Risk Assessment Process

The risk assessment process should align with the following steps:

##### (1) Scoping Assets

In order to begin the risk assessment process, the assessor should determine the scope of what needs to be covered in the assessment. An effective assessment should be limited in its scope to the applicable assets.

Such scoping activities may include:

• Review inventory of critical system assets (hardware, software, facilities, etc.)
• Identification of data owners (electronic and non-electronic data)
• Identification of workforce members with access to stored data by hardware/software
• Mapping data flow through raia and vendor systems
• Conducting an inventory of data storage (including non-electronic data)
• System characterization (e.g. essential, non-essential)

##### (2) Identifying Threats and Vulnerabilities

Vulnerabilities and the related threats, both internal and external, to raia operations (including, but not limited to, its mission, functions, image, or reputation), assets, information, and individuals may be identified and documented as part of the raia risk assessment.

Threat

A threat is any circumstance or event with the potential to adversely impact organizational operations and assets, individuals, or other organizations, through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service. [SP 800-30 Rev.1]

Vulnerability

A vulnerability is a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. [SP 800-30 Rev.1]

Vulnerabilities may be identified by the following:

• Vulnerability scanning and penetration tests
• Security control monitoring technologies
• Detected patterns, heuristics, or specific activities that indicate process gaps or technical weaknesses
• Internal and external audits
• External security vulnerabilities databases (e.g. CVE database) and reports

##### (3) Analyze Risks

For each risk, a risk owner has to be identified -- the person or organizational unit responsible for each risk. This person may or may not be the same as the asset owner. Once risk owners have been identified, it is necessary to assess consequences for each combination of threats and vulnerabilities for an individual asset if such a risk materializes:

Initial (or Inherent) Risk Likelihood Determination

How likely will an identified threat or vulnerability impact the organization given existing security controls?

The likelihood of occurrence is a weighted risk factor based on an analysis of the probability that a given threat is capable of exploiting a given vulnerability (or set of vulnerabilities). The likelihood factor is on a scale of 1 to 5, where 1 represents lowest likelihood and 5 represents highest likelihood.

Initial (or Inherent) Risk Impact Analysis

What is the cost if an identified threat or vulnerability impacts the organization given existing security controls?

The level of impact from a threat event is the magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability. The impact factor is on a scale of 1 to 5, where 1 represents lowest impact and 5 represents highest impact.

Initial (or Inherent) Risk Score

After the likelihood and impact analysis, a risk determination should be made. Risk is a function of the likelihood of a threat event's occurrence and potential adverse impact should the event occur. In order to determine risk score, raia multiplies impact * likelihood. The higher number equates to higher potential risk.

##### (4) Risk Treatment

For any critical or high risks identified during the risk assessment process, raia will immediately develop action plans to mitigate those risks which could include patching of vulnerable systems and/or applying other control activities. Risk responses shall consider obligations such as contractual agreements, laws, regulations and standards. The following items will have to be amended or defined based on discovered risk: IT policy and strategies, risk strategies, cost-effectiveness, type of protection, threats covered, risk levels, existing alternatives, and additional benefits derived from the treatment.

There are three possible responses to risk:

Risk Mitigation

Risk mitigation is the implementation of safeguards and countermeasures to reduce or eliminate vulnerabilities or threats.

Risk Transfer

Risk transfer is the placement of the cost of loss a risk represents onto another entity. This is accomplished by purchasing insurance and/or outsourcing.

Risk Acceptance

Acceptance of risk is the valuation by raia that the cost/benefit analysis of a possible safeguard and the determination that the cost of the countermeasure greatly outweighs the possible cost of loss due to a risk. Values under 3 are acceptable risks, while values 3+ are unacceptable risks. Unacceptable risks must be treated. On behalf of the risk owners, Senior Management will accept all residual risks.

##### (5) Calculate Residual Risks

Based on risk treatment decisions, plans, and net new compensating controls to be implemented, residual risks must be calculated, reassessing the respective initial risks' likelihoods and impacts.

##### (6) Reporting

Richard Swier or a designee is responsible for creating the risk assessment and treatment report and delivering results to senior management and other applicable personnel. This report shall include risk responses and documentation of risks that will be accepted by the organization such as threats or vulnerabilities that will likely impact the organization and with a low impact cost. All risk assessment reports must be documented and retained for a minimum of three years.

Unacceptable risks should be appropriately remediated or mitigated in accordance with the Change Management Policy and Vulnerability Management Policy.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee's or contractor's course and scope of work.

Any personnel who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

Richard Swier or a designee is responsible for overseeing the successful completion of the risk assessment. Such risk assessments must be conducted at least annually or whenever there are significant changes to raia, its systems, or other conditions that may impact the security of raia such as the failure of a mission critical vendor or a security breach.

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

Purpose and Scope

The purpose of this document is to define basic rules for secure development of software and systems.

This document is applied to the development and maintenance of all services, architecture, software and systems that make up raia's product/service.

Users of this document are all employees and applicable contractors who are involved with the development and maintenance of applications and systems at raia.

Secure Development and Maintenance

Securing the Development Environment

Access to the development environment is restricted only to authorized employees via logical access control. Development and production environments are logically separated.

Secure Engineering Principles

raia developers follow secure information system engineering practices for the development of new systems and for the maintenance of the existing systems. Minimum-security standards must be maintained and complied with when implementing new systems.

The same secure engineering principles are applied to outsourced development.

All developed code should be reviewed, utilizing the following peer review best practices: https://google.github.io/eng-practices/review/reviewer/.

Security Requirements Related to Public Networks

Richard Swier is responsible for defining security controls related to information in application services passing over public networks:

• the description of authentication systems to be used
• the description of how confidentiality and integrity of information is to be ensured
• the description of how non-repudiation of actions will be ensured

Richard Swier is responsible for defining controls for online transactions, which must include the following:

• how misrouting will be prevented
• how incomplete data transmission will be prevented
• how unauthorized message alteration will be prevented
• how unauthorized message duplication will be prevented
• how unauthorized data disclosure will be prevented

Repository and Version Control

raia utilizes GitHub as its code version control management tool to track and manage code development, testing, and merges with production. Changes in the development and during the maintenance of the systems must be done according to the Change Management Policy.

Protection of Test Data

Confidential and restricted data, as well as data that can be related to individual persons should not be used as test data, except as required for customer debugging, where approved by customers or where approved by management. On a similar note, test data should be restricted from entering the production environment.

Required Security Training

All engineers must periodically review the OWASP Top 10 as defined in the Change Management Policy.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any personnel who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

raia

Purpose and Scope

The Security Incident Response Plan - HIPAA Addendum identifies the requirements for covered entities and business associates in providing notification to affected individuals, the Secretary, and, in certain circumstances, to the media following a breach of unsecured protected health information.

This addendum applies to all breaches of protected health information (PHI) covered under the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”).

HIPAA Breach Notification Policy

In the event that individually identifiable health information is affected during a breach, the following HIPAA Breach Notification Policy shall apply:

raia has adopted this HIPAA Breach Notification Policy in order to comply with the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”), as amended by the HITECH Act of 2009 (ARRA Title XIII). raia also recognizes its responsibility to protect individually identifiable health information under the regulations implementing HIPAA, other federal and state laws protecting the confidentiality of personal information, and under general, professional ethics.

The following governs consumer notifications of breaches of individually identifiable health information for raia.

Assumptions

raia understands that in some instances it may be a Business Associate under the definitions contained in the HIPAA regulations.

When applicable, raia must comply with HIPAA and the HIPAA implementing regulations concerned with notifications to consumers about breaches of individually identifiable health information, in accordance with the requirements at § 164.400 to § 164.414.

Compliance with HIPAA’s breach notification requirements is mandatory and failure to comply can bring severe sanctions and penalties.

Timely notifications to consumers about breaches of individually identifiable health information can help reduce or prevent identity theft and fraud.

Timely notifications to consumers about breaches of individually identifiable health information can help protect our business and reputation.

Only breaches of “unsecured” (unencrypted or not destroyed) protected health information trigger HIPAA’s breach notification requirements.

Breach Notification Policy

It is the policy of raia to provide timely notifications to affected parties about breaches of individually identifiable health information.

Model breach notification letters or emails may be developed and prepared to be used as needed.

It is the policy of raia to timely provide:

• Notice to parties alerting them to breaches “without unreasonable delay,” but no later than 60 days after discovery of the breach.
• Notice to Covered Entities (CEs) by Business Associates (“BAs”) when BAs discover a breach.
• Notice to the secretary of HHS and prominent media outlets about breaches involving more than 500 individual subject’s records.
• Notice to next of kin about breaches involving parties who are deceased.
• Notices to include what happened, the details of the breached Protected Health Information (PHI) or electronic PHI (ePHI), steps to help mitigate harm to the party, and the CE’s response.
• Annual notice to the secretary of HHS 60 days before the end of the calendar year about PHI breaches involving fewer than 500 patient records.

When a security or privacy incident occurs that may be a “breach” under HIPAA regulations, the designated Officer (Richard Swier, Founder and Information Security Team Lead) will perform a risk assessment to determine whether there is significant risk of harm to the individual(s) whose PHI was inappropriately disclosed or compromised. The following questions must be accurately addressed by the risk analysis:

• Did the breach or compromise involve “unsecured” protected health information?
• In whose hands did the PHI land?
• Can the information disclosed cause “significant risk of financial, reputational, or other harm to the individual”?
• Was mitigation possible? For example, can you obtain forensic proof that a stolen laptop computer’s data were not accessed?

Business Associate contracts, whether existing or new, are required to have corresponding breach notification requirements included in them.

Sanctions or re-training shall be applied to all workforce members who caused or created the conditions that allowed the breach to occur.

All breach-related activities and investigations shall be thoroughly and timely documented in accordance with this Plan.

Exceptions

If a law enforcement official states to a covered entity or business associate that a notification, notice, or posting required under this subpart would impede a criminal investigation or cause damage to national security, a covered entity or business associate shall:

(a) If the statement is in writing and specifies the time for which a delay is required, delay such notification, notice, or posting for the time period specified by the official; or

(b) If the statement is made orally, document the statement, including the identity of the official making the statement, and delay the notification, notice, or posting temporarily and no longer than 30 days from the date of the oral statement, unless a written statement as described in paragraph (a) of this section is submitted during that time.

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

This plan will be reviewed and tested on an annual basis. Ensuring that the plan reflects ongoing changes to resources is crucial. This task includes updating the plan and revising this document to reflect updates; testing the updates; and training personnel. Test results will be documented and signed off by raia management. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is tested, maintained and enforced by Richard Swier.

This document was last updated on May 7, 2026.

Purpose and Scope

The Security Incident Response Plan provides a systematic incident response process for all Information Security Incident(s) (defined below) that affect any of raia's information technology systems, network, or data, including raia data held or services provided by third-party vendors or other service providers. From time to time, raia may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations.

This plan applies to all raia assets utilized by personnel acting on behalf of raia or accessing its applications, infrastructure, systems or data. All personnel are required to read, accept and follow all raia policies and plans.

raia intends for this plan to:

• Define the raia security incident response process and provide step-by-step guidelines for establishing a timely, consistent, and repeatable incident response process.
• Assist raia and any applicable third parties (including vendors and partners) in quickly and efficiently responding to and recovering from different levels of information security incidents.
• Mitigate or minimize the effects of any information security incident on raia, its customers, employees, and others.
• Help raia consistently document the actions it takes in response to information security incidents.

“Information Security Incident” means an actual or reasonably suspected unauthorized use, disclosure, acquisition of, access to, corruption of, deletion, or other unauthorized processing of sensitive information that reasonably may compromise the privacy, confidentiality, integrity, or availability of that information.

Management

raia has a Security Response Team (SRT) consisting of predetermined employees from key departments at raia to manage security incidents. The SRT provides timely, organized, informed, and effective response to information security incidents to (a) avoid loss of or damage to the raia systems, network, and data; (b) minimize economic, reputational, or other harms to raia and its customers, employees, contractors and partners; and (c) manage litigation, enforcement, and other risks.

The SRT also oversees and coordinates the development, maintenance and testing of the plan, its distribution, and on-going updates of the plan. The Security Incident Response Plan is activated or enabled when a security incident occurs, and the SRT is responsible for evaluating the situation and responding accordingly. Depending on the severity of an incident the SRT may request engagement from various support teams to assist with the mitigation of the incident.

The SRT meets on a periodic basis for training, education, and review of the documented plan. The SRT consists of a core team with representatives from key raia groups and stakeholders. The current SRT roster includes Richard Swier (lead) and Thomas Hall, and may be contacted at r@raiaai.com.

Incident Response Process

The process outlined below should be followed by the appropriate Staff at raia in the event of an Information Security Incident. raia shall assign resources and adopt procedures to timely assess automated detection results, screen internal and external reports, and identify actual information security events. raia shall document each identified Information Security Incident.

Detection and Reporting

Automated Detection

raia may utilize automated detection means and other technical safeguards to automatically alert raia of incidents or potential incidents.

Report from raia Personnel

All raia personnel must report potential security incidents as follows:

• If you believe an incident occurred or may occur or may have identified a threat, vulnerability, or other security weakness, please report it to the following email immediately: r@raiaai.com;
• Provide all available information and data regarding the potential incident; and
• Once an incident has been submitted, please stop using the affected system, or any other potentially affected device until being given the okay from the SRT.

Report from External Source

External sources, including raia's customers, who claim to have information regarding an actual or alleged information security incident should be directed to r@raiaai.com.

Employees who receive emails or other communications from external sources regarding information security incidents that may affect raia or others, security vulnerabilities, or related issues should immediately report those communications to r@raiaai.com and should not interact with the source unless authorized.

Response Procedures

Overview

Responding to a data breach involves the following stages:

1. Verification
2. Assessment
3. Containment and mitigation
4. Post-breach response

All of the steps must be documented in an incident log and/or corrective action plan.

The data breach response is not purely linear, as these stages and the activities associated with these stages frequently overlap. raia must keep a record of any actions the organization takes in responding to the incident and preserve any evidence that may be relevant to any potential regulatory investigation or litigation including through use of an incident log, corrective action plan or other applicable documentation.

(1) Verification

The SRT will work with raia employees and contractors to identify the affected systems or hardware (such as a lost laptop or USB drive) and determine the nature of the data maintained in those systems or on the hardware.

The SRT will determine the threshold at which events are declared a security incident and officially initiate the incident response process.

(2) Assessment

Following verification of an Information Security Incident, the SRT will determine the level of response required based on the incident's characteristics, including affected systems and data, and potential risks and impact to raia and its customers, employees, or others.

The incident assessment must include what employees or contractors were affected, what customers were affected, and what data was potentially exfiltrated, modified, deleted or compromised.

The SRT will work together to assess a priority with respect to the incident based on factors such as whether:

• the incident exposed or is reasonably likely to have exposed data; or
• personally identifiable information was affected and the data elements possibly at risk, such as name or date of birth.

In addition, the SRT will consider whether the disclosure was:

• internal or external;
• caused by a company insider or outside actor; and/or
• the result of a malicious attack or an accident.

Lastly, if an information security breach has occurred, federal/country-wide law enforcement and local law enforcement should be contacted and informed of the breach. Law enforcement should be contacted in alignment with applicable breach notification laws. Internal and/or external general counsel should lead law enforcement communication efforts (in collaboration with SRT). If general counsel is not available, SRT should lead law enforcement communication efforts.

(3) Containment and Mitigation

As soon as raia has verified and assessed the breach, the SRT must take all necessary steps to contain the incident and return the raia systems back to their original state and limit further data loss or intrusion.

Such steps may include:

• Acting to stop the source or entity responsible, for example by:
• taking affected machines offline;
• segregating affected systems; or
• immediately securing the area if the breach involves a physical security breach.
• Determining whether other systems are under threat of immediate or future danger.
• Determining whether to implement additional technical measures to contain the data breach, such as changing locks, passwords, administrative rights, access codes, or passwords.

(4) Post-Breach Response

Any post-breach response including external and internal communications, notifications, and further inquiries will depend on the assessment and priority of the data breach.

raia will respond to confirmed disclosures affecting data subjects in accordance with breach notice periods defined in applicable laws and regulations.

As part of the final response based on the results of the breach, raia will review applicable access controls, policies and procedures and determine whether to take any actions to strengthen the organization's information security program.

Regulatory Notification Requirements

GDPR Breach Notification (EU/EEA Data Subjects)

Where a personal data breach involves the data of individuals located in the European Union or European Economic Area, raia must comply with the following notification obligations under the General Data Protection Regulation (EU) 2016/679:

Notification to Supervisory Authority (Article 33):

• raia must notify the relevant supervisory authority within 72 hours of becoming aware of a personal data breach that is likely to result in a risk to the rights and freedoms of natural persons.
• If notification cannot be made within 72 hours, the notification must be accompanied by documented reasons for the delay.
• The notification must include:
• A description of the nature of the breach, including the categories and approximate number of data subjects and personal data records affected;
• The name and contact details of raia's designated privacy contact (r@raiaai.com);
• A description of the likely consequences of the breach; and
• A description of the measures taken or proposed to address the breach, including measures to mitigate its possible adverse effects.
• Where it is not possible to provide all information at the same time, the information may be provided in phases without undue further delay.

Communication to Data Subjects (Article 34):

• When the breach is likely to result in a high risk to the rights and freedoms of affected individuals, raia must communicate the breach to those individuals without undue delay.
• The communication must describe in clear and plain language the nature of the breach and contain at minimum the contact point, likely consequences, and measures taken.
• Communication to data subjects is not required if:
• raia has implemented appropriate technical and organizational protection measures (e.g., encryption) that render the personal data unintelligible to unauthorized persons;
• raia has taken subsequent measures that ensure the high risk is no longer likely to materialize; or
• It would involve disproportionate effort, in which case a public communication or similar measure shall be used instead.

Processor Obligations:

Where raia acts as a data processor on behalf of a controller, raia must notify the controller without undue delay after becoming aware of a personal data breach, enabling the controller to meet its own 72-hour notification obligation.

NIS2 Directive Obligations (EU 2022/2555)

If raia is determined to fall within the scope of the NIS2 Directive as a digital service provider, the following incident reporting timeline applies for significant incidents:

• Early warning within 24 hours of becoming aware of a significant incident — indicating whether the incident is suspected of being caused by unlawful or malicious acts or could have cross-border impact;
• Incident notification within 72 hours — providing an initial assessment of the incident, including its severity and impact, and indicators of compromise where available;
• Final report within one month — including a detailed description of the incident, its root cause, mitigation measures applied, and any cross-border impact.

U.S. State Breach Notification Laws

raia will comply with all applicable U.S. state breach notification laws, which generally require notification to affected individuals within 30 to 60 days of discovery, depending on the jurisdiction. Where a breach affects 500 or more residents of a single state, notification to the state attorney general may also be required.

HIPAA Breach Notification

For breaches involving Protected Health Information (PHI), refer to the Security Incident Response Plan — HIPAA Addendum for specific notification timelines and procedures.

Notification Decision Matrix

The SRT shall use the following framework to determine notification obligations:

• Severity 1 (Critical): Confirmed breach of personal data affecting EU/EEA data subjects — initiate 72-hour GDPR notification clock immediately upon awareness. If NIS2 applies, issue early warning within 24 hours.
• Severity 2 (High): Confirmed breach of personal data affecting non-EU data subjects — follow applicable U.S. state notification timelines (generally 30-60 days).
• Severity 3 (Medium): Suspected breach under investigation — document timeline of awareness, begin assessment, and prepare notification materials in parallel.
• Severity 4 (Low): Security event contained with no evidence of data exfiltration — document in incident log; no external notification required unless risk assessment changes.

Key Learnings

As soon as the incident has been resolved, raia senior management should meet with the SRT and other relevant team members of the raia for a post-mortem to better understand the incident that took place, and determine how similar incidents may be prevented in the future.

The retrospective should be documented and key learnings from the retrospective should be presented to all appropriate team members in a timely manner.

Testing

Testing the plan annually is critical to ensuring the plan is effective and practical. Any gaps in the plan that are discovered during the testing phase will be addressed by raia management. All tests must be thoroughly documented.

Testing of this plan may be performed using the following methods:

Walkthroughs

Team members walk through the steps documented in this plan to confirm effectiveness, identify gaps, bottlenecks or other weaknesses. This walkthrough provides the opportunity to review the plan with a larger subset of people, allowing the team to draw upon an increased pool of knowledge and experiences. Team members should be familiar with procedures, equipment, and offsite facilities.

Table Top Exercises

An incident is simulated so normal operations will not be interrupted. Scenarios of various security incidents are used and this plan is put into action to determine its use and effectiveness.

Validated checklists can provide a reasonable level of assurance for many of these scenarios. Analyze the output of the previous tests carefully before the proposed simulation to ensure the lessons learned during the previous phases of the cycle have been applied.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any employee or contractor who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

This plan will be reviewed and tested on an annual basis. Ensuring that the plan reflects ongoing changes to resources is crucial. This task includes updating the plan and revising this document to reflect updates; testing the updates; and training personnel. Test results will be documented and signed off by raia management. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is tested, maintained, approved and enforced by Richard Swier.

This document was last updated on May 7, 2026.

Purpose and Scope

This Vendor Management Policy guides raia in the execution, management, and termination of vendor and other third party agreements. From time to time, raia may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations. This policy is guided by security requirements specific to raia including applicable laws and regulations.

This policy applies to all raia assets utilized by employees and contractors acting on behalf of raia or accessing its applications, infrastructure, systems or data. All employees and contractors are required to read, accept and follow all raia policies and plans.

Vendor Management Process

raia will maintain a profile of all raia vendors that includes the vendor, their executed agreements, and the appropriate reviews and documentation of such vendors in accordance with this policy. Such reviews will be based on the risk level of each vendor.

In order for raia to contract with a new vendor, the following steps should be taken in advance:

(1) Request for New Vendor

If an employee or contractor of raia wishes to use the free or paid services of a new vendor, a request for such use must be submitted to your manager. As part of the submission, the request may include a completed raia new vendor request form.

(2) Risk Assessment and Due Diligence

Before entering into a contract and granting access to raia systems, a risk assessment and appropriate due diligence should be performed to determine the possible risk and impact to raia. Vendors should be separated into three risk tiers: High, Medium and Low. Risk assessments must occur for all high risk vendors.

In particular, a vendor security assessment should include answers to at least the following:

• Is the vendor of a customer-facing nature?
• Would the vendor be involved in receiving and storing confidential data. Examples include: customer data, employee data, regulatory data, or financial data?
• If so, where does the vendor use, access, and store such data?
• What security controls and measures does the vendor have in place?
• Request copies of all relevant security policies.
• Has the vendor undergone third party audits (such as SOC2, HITRUST, ISO)?
• If so, a review of such reports should be performed and identified weaknesses should be documented
• Is there a risk of regulatory scrutiny and customer harm associated with the vendor?
• What is the operational reliance on this vendor?
• Does this vendor present supply chain risk?

(3) Contract Review

A confidentiality agreement or services agreement containing a confidentiality clause or equivalent must be reviewed and executed prior to any use of services and sharing of confidential data between raia and any third-party.

Vendor agreements should at a minimum require that third-parties maintain the privacy and security of the confidential information stored, used, or disclosed on behalf of raia.

(4) Monitoring of Vendors

Richard Swier or a designee is responsible for annual or more frequent vendor reviews of high-risk vendors as determined by this policy.

raia must periodically review all third-party agreements to reasonably ensure that vendors remain in compliance with state and federal law and appropriately address any legal risk to raia. Agreements will be updated and amended as necessary when business and regulatory requirements change.

Annual reviews of vendors will be documented and retained for audit purposes. The annual review may include the gathering of applicable compliance audits (SOC 1, SOC 2, PCI DSS, HITRUST, ISO 27001, etc.) or other evidence of security compliance including performing a review of in-place security controls.

Results of the reviews must be compared to in-place agreements and/or SLAs to ensure that services are being provided as intended. If vendors are found to be in violation of any executed agreement(s), action plans and processes may be initiated to remedy the issue(s) or access to raia systems may be removed immediately.

(5) Termination of Vendors

Upon termination of a vendor's services, all confidential information stored by the vendor should be deleted and/or provided back to raia within 60 days.

(6) Assignment of Vendor Relationship Owners and Contacts

Vendors should be assigned internal relationship owners, and key external vendor contacts should be identified. Vendor contacts should be actively maintained in case any issues with the vendor's product or service arise.

GDPR and European Data Protection Requirements for Vendors

Where a vendor processes personal data on behalf of raia in relation to EU/EEA data subjects, the following additional requirements apply in accordance with the General Data Protection Regulation (GDPR):

Data Processing Agreements (Article 28)

raia must execute a Data Processing Agreement (DPA) with any vendor that processes personal data on its behalf. The DPA must specify:

• The subject matter and duration of the processing;
• The nature and purpose of the processing;
• The type of personal data and categories of data subjects;
• The obligations and rights of raia as controller.

The DPA must require the processor to:

• Process personal data only on documented instructions from raia;
• Ensure that persons authorized to process personal data have committed themselves to confidentiality;
• Take all measures required pursuant to Article 32 (security of processing);
• Not engage another processor without prior specific or general written authorization from raia;
• Assist raia in responding to data subject rights requests;
• Assist raia in ensuring compliance with breach notification obligations (including enabling raia to meet the 72-hour supervisory authority notification deadline);
• Delete or return all personal data at the end of the provision of services; and
• Make available to raia all information necessary to demonstrate compliance and allow for audits.

International Data Transfers

Where a vendor transfers personal data outside the EU/EEA, appropriate safeguards must be in place, including:

• An adequacy decision by the European Commission for the destination country;
• Standard Contractual Clauses (SCCs) approved by the European Commission; or
• Binding Corporate Rules approved by a supervisory authority.

raia must verify and document the transfer mechanism in use for each vendor that processes EU/EEA personal data in a third country.

Sub-processor Management

Vendors acting as processors must inform raia of any intended changes concerning the addition or replacement of sub-processors, giving raia the opportunity to object to such changes. Sub-processors must be bound by the same data protection obligations as set out in the DPA between raia and the vendor.

Vendor Security Controls

In order to protect raia, certain high-risk vendors may require additional controls such as:

• Not to use or further disclose confidential information other than as permitted or required by the agreement or as required by law
• Define the following service levels, where applicable:
• Service definitions,
• Delivery levels,
• Security controls,
• Aspects of service management, and
• Issues of liability, reliability of services, and response times
• Use appropriate safeguards to prevent use or disclosure of confidential information other than as provided for by the agreement
• Employ or implement appropriate administrative, physical, and technical security safeguards and privacy practices that meet the use and disclosure requirements of raia
• Require a prompt report of any inappropriate use, disclosure or breaches of confidential information
• Breach notification must include the following:
• names of breached individual(s) and contact information,
• date breach occurred and the date breach was discovered,
• information/data that was breached (e.g., social security number, name, address, etc.),
• mitigating activity undertaken to limit damages, and
• security controls that will be implemented to reasonably ensure a similar breach does not occur in the future
• Reasonably ensure that any agents, including subcontractors, who use and disclose confidential information will agree to the same restrictions and conditions that apply to raia and its team members.
• Require that third-parties coordinate, manage, and communicate changes to any services currently provided that could affect the security, availability, or integrity of covered data.
• Review warranties, indemnification and limitations of liability to determine maximum cost of risk.
• Upon termination of the agreement, if feasible, the service provider or vendor will return or destroy all confidential information, used or disclosed by the service provider on behalf of raia, in any form and will retain no copies of such information.
• If return or destruction is not feasible, the service provider may extend the agreement’s privacy and security protections to confidential information and limit further uses and disclosures to those purposes that make the return or destruction of confidential information infeasible.
• Authorize raia to terminate the agreement if raia determines the service provider or vendor has or is violating the executed agreement.

Exceptions

raia business needs, local situations, laws and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any personnel who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

raia

Vulnerability and Patch Management Policy

Purpose and Scope

This Vulnerability Management Policy defines an approach for vulnerability management to reduce system risks and integrate with patch management. From time to time, raia may update this policy and implement different levels of security controls for different information assets, based on risk and other considerations. This policy is guided by security requirements specific to raia including applicable laws and regulations.

This policy applies to all raia assets utilized by personnel acting on behalf of raia or accessing its applications, infrastructure, systems or data. All personnel are required to read, accept, and follow all raia policies and plans.

Vulnerability and Patch Management Program

raia maintains a vulnerability management process that is integrated into the Change Management Process.

raia may periodically test the security posture of its applications and systems through third-party testing as well as vulnerability scanning.

raia also monitors multiple security alert lists such as the CVE Database and US-CERT to get up to date information on the latest vulnerabilities and threats.

Third-Party Penetration and Vulnerability Tests

raia schedules third party security assessments, penetration tests, and/or dynamic analysis tests at least annually.

raia periodically performs vulnerability scans.

Identifying Vulnerabilities

raia reviews third-party penetration test reports and vulnerability scan results to verify vulnerabilities and determine impact.

Scoring Vulnerabilities

Vulnerabilities are derived from the Common Vulnerabilities and Exposures (CVE) Database and are documented and scored based upon the Common Vulnerability Scoring System (CVSS) standard.

Mitigating Vulnerabilities

If remediation is required, the appropriate team member at raia will be notified of the requirements to remediate or mitigate the vulnerability and the time frame of such requirement will depend on the severity and risk of the vulnerability. Such tracking of vulnerabilities must be done through the company's change management tool (e.g., GitHub, Confluence) and in accordance with the Change Management Process.

The information obtained from the vulnerability scanning process will be shared with appropriate personnel throughout the organization on a “need to know” basis to help eliminate similar vulnerabilities in other information systems.

Patching

All system components, software and production environments shall be protected from known vulnerabilities by installing applicable vendor supplied security patches. Other patches not designated as critical by the vendor shall be applied on a normal maintenance schedule as defined by normal systems maintenance and support operating procedures.

System and Non-Company Application Patching

Patching includes updates to all operating systems and third party applications as provided by the appropriate vendor.

raia Application Patching

raia applications are patched in accordance with the Change Management Policy. Patches deemed to be of a high or critical nature may be rolled out in a compressed schedule as set forth in such policy.

Patching Exceptions

Patching production systems (e.g. servers and enterprise applications) may require complex testing and installation procedures. In certain cases, risk mitigation rather than patching may be preferable. The risk mitigating alternative should be determined through a documented risk analysis.

Exceptions

raia business needs, local situations, laws, and regulations may occasionally call for an exception to this policy or any other raia policy. If an exception is needed, raia management will determine an acceptable alternative approach.

Enforcement

Any violation of this policy or any other raia policy or procedure may result in disciplinary action, up to and including termination of employment. raia reserves the right to notify the appropriate law enforcement authorities of any unlawful activity and to cooperate in any investigation of such activity. raia does not consider conduct in violation of this policy to be within an employee’s or contractor’s course and scope of work.

Any personnel who is requested to undertake an activity that he or she believes is in violation of this policy must provide a written or verbal complaint to his or her manager or any other manager of raia as soon as possible.

The disciplinary process should also be used as a deterrent to prevent employees and contractors from violating organizational security policies and procedures, and any other security breaches.

Responsibility, Review, and Audit

raia reviews and updates its security policies and plans to maintain organizational security objectives and meet regulatory requirements at least annually. The results are shared with appropriate parties internally and findings are tracked to resolution. Any changes are communicated across the organization.

This document is approved by Richard Swier.

This document was last updated on May 7, 2026.

Last Updated: May 8, 2026

1. Purpose and Scope

In its everyday business operations, RAIA LLC ("RAIA," "we," "us," or "our") makes use of a variety of personal data, including data about:

• Current, past, and prospective employees
• Customers and their end users
• Users of and visitors to its websites (raiaai.com, raiabot.com, raiaagent.com)
• Subscribers
• Other stakeholders

In collecting and using this data, RAIA is subject to privacy and data protection legislation in multiple jurisdictions. The purpose of this policy is to set out the relevant legislation and to describe the steps RAIA is taking to ensure compliance.

This policy applies to all systems, people, and processes that constitute RAIA's information systems, including board members, directors, employees, suppliers, and other third parties who have access to RAIA systems.

Use of RAIA's services is also governed by our Terms of Service, which include important disclaimers regarding AI-generated outputs, messaging responsibilities, acceptable use, and limitations of liability. This Privacy Policy and our Terms of Service should be read together.

2. Applicable Privacy Legislation

RAIA complies with all applicable privacy laws, including but not limited to:

• European Union — General Data Protection Regulation (GDPR) (EU) 2016/679
• United Kingdom — UK GDPR and Data Protection Act 2018
• United States (California) — California Consumer Privacy Act (CCPA) / California Privacy Rights Act (CPRA)
• United States (Other States) — Virginia CDPA, Colorado CPA, Connecticut CTDPA, and other applicable state privacy laws
• Canada — PIPEDA; Quebec Act respecting the protection of personal information (Law 25)
• Brazil — General Data Protection Law (LGPD)
• Australia — Privacy Act 1988; Privacy and Personal Information Protection Act
• Singapore — Personal Data Protection Act (PDPA)
• Argentina — Personal Data Protection Law (PDPL)

RAIA ensures that its compliance with applicable legislation is clear and demonstrable at all times.

3. Data Controller and Data Processor

When RAIA is the Data Controller: RAIA acts as the data controller for personal data collected through its websites, marketing activities, and direct business relationships (e.g., visitor data, prospect data, employee data).

When RAIA is the Data Processor: When customers use RAIA's platform to send emails, SMS/MMS messages, voice calls, or live chat messages, the customer acts as the data controller under applicable law. RAIA processes contact data solely on the customer's instructions as a data processor.

• Customers are solely responsible for obtaining all legally required consents before sending communications.
• Customers must comply with all applicable privacy, data protection, and anti-spam laws, including the TCPA, CAN-SPAM Act, GDPR, CASL, and ePrivacy Directive.
• RAIA is not responsible or liable for the content of customer messages, compliance with consent requirements, or any legal violations resulting from customer communications.

Data Processing Agreement (DPA): Enterprise customers who require a Data Processing Agreement in accordance with GDPR Article 28 may request one by contacting privacy@raiaai.com. Our DPA includes Standard Contractual Clauses (SCCs) for international data transfers.

4. Definitions

• Personal Data: Any information that can identify a natural person or be linked to them directly or indirectly.
• Data Subject / Personal Data Principal: The individual to whom the personal data relates.
• Processing: Any operation performed on personal data, such as collection, storage, use, disclosure, or deletion.
• Data Controller: The party that determines the purposes and means of processing personal data.
• Data Processor: The party that processes personal data on behalf of a data controller.
• Sub-processor: A third-party processor engaged by RAIA to process personal data on behalf of a customer.
• Supervisory Authority: An independent public authority responsible for monitoring the application of data protection law (e.g., a Data Protection Authority in the EU).

5. Personal Data We Collect

5.1 Data Collected Directly

• Account Information: Name, email address, company name, phone number, job title
• Billing Information: Payment card details (processed by Stripe; RAIA does not store full card numbers), billing address
• Communications: Correspondence with our support team, feedback, and survey responses
• Usage Data: Log data, device information, IP address, browser type, pages visited, features used

5.2 Data Collected Automatically

• Cookies and Similar Technologies: See Section 11 (Cookie Policy) below
• Analytics Data: Aggregated usage statistics to improve our services
• Security Logs: Authentication events, access logs, and security-related data

5.3 Data Processed on Behalf of Customers

• Customer Contact Data: Phone numbers, email addresses, names, and other contact information uploaded by customers for use with RAIA's communication platform
• Message Content: Content of messages sent through the platform (emails, SMS, chat)
• AI Interaction Data: Inputs provided to and outputs generated by RAIA's AI agents

6. AI-Generated Personal Data

RAIA's AI-powered tools may generate outputs that contain personal data or inferences about individuals based on inputs provided by customers.

• Customers are solely responsible for reviewing any AI-generated content before using it.
• RAIA does not guarantee the accuracy, legality, or appropriateness of AI outputs.
• Customers must ensure that the use of AI outputs complies with all applicable privacy, data protection, and ethical standards.
• RAIA does not use customer data to train its AI models without explicit customer consent.

7. Purposes and Lawful Basis for Processing

RAIA processes personal data for the following purposes:

8. Principles for Processing Personal Data

RAIA adheres to the following privacy principles in accordance with GDPR Article 5:

• Lawfulness, fairness, and transparency — Data must be processed legally, fairly, and transparently.
• Purpose limitation — Data must only be collected for specified, legitimate purposes.
• Data minimization — Only the data necessary for the purpose is collected.
• Accuracy — Data must be accurate and kept up to date.
• Storage limitation — Data must be retained only as long as necessary.
• Integrity and confidentiality — Data must be secured against unauthorized access, loss, or damage.
• Accountability — RAIA is responsible for demonstrating compliance with these principles.

9. Rights of Individuals

Depending on your jurisdiction, you may have the following rights regarding your personal data:

• Right to be informed — To know how your data is being used
• Right of access — To obtain a copy of your personal data
• Right to rectification — To correct inaccurate personal data
• Right to erasure ("right to be forgotten") — To request deletion of your personal data
• Right to restrict processing — To limit how your data is used
• Right to data portability — To receive your data in a structured, machine-readable format
• Right to object — To object to processing based on legitimate interests or direct marketing
• Rights related to automated decision-making and profiling — To not be subject to solely automated decisions with legal effects
• Right to withdraw consent — Where processing is based on consent, to withdraw that consent at any time
• Right to lodge a complaint — To file a complaint with a supervisory authority

How to exercise your rights: Submit requests to privacy@raiaai.com. RAIA will respond within 30 days (or within the timeframe required by applicable law). We may request verification of your identity before processing requests. For EU/EEA residents, the response period is one month from receipt, extendable by two further months for complex requests.

California Residents (CCPA/CPRA): You have the right to know what personal information is collected, to request deletion, to opt out of the sale or sharing of personal information, and to not be discriminated against for exercising your rights. RAIA does not sell personal information.

10. Data Retention

RAIA retains personal data only for as long as necessary to fulfill the purposes for which it was collected:

Upon expiration of the retention period, data is securely deleted or anonymized in accordance with our Data Retention and Disposal Policy.

11. Cookie Policy

11.1 What Are Cookies

Cookies are small text files placed on your device when you visit our websites. They help us provide a better user experience and understand how our sites are used.

11.2 Types of Cookies We Use

11.3 Managing Cookies

You can control cookies through your browser settings. You may also use our cookie consent banner to accept or decline non-essential cookies. Disabling certain cookies may affect site functionality.

11.4 Third-Party Cookies

We use the following third-party services that may set cookies:

• Analytics: Umami (privacy-focused, no personal data collection)
• Payment Processing: Stripe
• Customer Communication: Intercom

12. Security Measures

RAIA implements appropriate technical and organizational measures to protect personal data, including:

• Encryption: All data is encrypted in transit (TLS 1.2+) and at rest (AES-256)
• Access Controls: Role-based access control, multi-factor authentication, and least-privilege principles
• Infrastructure: Hosted on Google Cloud Platform with SOC 2 Type II certified infrastructure
• Monitoring: Continuous security monitoring, intrusion detection, and vulnerability scanning
• Employee Training: Regular security awareness training for all personnel
• Incident Response: Documented incident response procedures with defined notification timelines
• Certifications: RAIA maintains SOC 2 Type II compliance and HIPAA compliance

For more information about our security practices, please visit our Security page or contact r+security@raiaai.com.

13. Sub-Processors

RAIA engages the following categories of sub-processors to deliver its services:

Customers who have executed a DPA will be notified of changes to sub-processors in accordance with the terms of their agreement. A current list of sub-processors is maintained and available upon request at privacy@raiaai.com.

14. International Data Transfers

RAIA's primary data processing occurs in the United States. When personal data is transferred from the European Economic Area (EEA), United Kingdom, or Switzerland to the United States or other countries without an adequacy decision, RAIA ensures appropriate safeguards are in place:

• Standard Contractual Clauses (SCCs): We use EU Commission-approved SCCs for transfers to third countries.
• Data Processing Agreements: Our DPAs incorporate transfer mechanisms as required by GDPR Chapter V.
• Transfer Impact Assessments: We conduct assessments to evaluate the legal framework of recipient countries.
• Supplementary Measures: Where necessary, we implement additional technical and organizational measures (e.g., encryption, pseudonymization) to ensure an essentially equivalent level of protection.

15. Data Breach Notification

In the event of a personal data breach that poses a risk to individual rights and freedoms:

• Supervisory Authority Notification: RAIA will notify the relevant supervisory authority within 72 hours of becoming aware of the breach, as required by GDPR Article 33.
• Data Subject Notification: Where the breach is likely to result in a high risk to individuals, RAIA will notify affected data subjects without undue delay, as required by GDPR Article 34.
• Customer Notification: Where RAIA acts as a data processor, we will notify the affected customer (data controller) without undue delay to enable them to meet their own notification obligations.
• U.S. State Law Compliance: RAIA will comply with all applicable U.S. state breach notification laws, which generally require notification within 30 to 72 days depending on the jurisdiction.

16. Data Protection Impact Assessments

RAIA conducts Data Protection Impact Assessments (DPIAs) where processing is likely to result in a high risk to the rights and freedoms of individuals, including:

• Large-scale processing of personal data
• Systematic monitoring of individuals
• Processing of sensitive categories of data
• New technologies or novel processing activities

17. Privacy by Design and Default

RAIA incorporates privacy considerations into all new or significantly changed systems that collect or process personal data. This includes:

• Minimizing data collection to what is strictly necessary
• Implementing appropriate security measures from the design phase
• Ensuring privacy-friendly default settings
• Conducting privacy impact assessments where necessary

18. Children's Privacy

RAIA's services are not directed to individuals under the age of 18. We do not knowingly collect personal data from children. If we become aware that we have collected personal data from a child, we will take steps to delete that information promptly.

19. Do Not Sell or Share My Personal Information

RAIA does not sell personal information as defined under the CCPA/CPRA. RAIA does not share personal information for cross-context behavioral advertising purposes. If you wish to exercise your rights under the CCPA/CPRA, please contact privacy@raiaai.com.

20. Compliance Measures

RAIA ensures compliance by:

• Maintaining a clear legal basis for all data processing activities
• Training staff on privacy responsibilities
• Providing clear procedures for handling data subject requests
• Conducting regular reviews of privacy practices
• Documenting all processing activities (Records of Processing Activities under GDPR Article 30)
• Appointing responsible personnel for data protection oversight
• Conducting annual privacy audits

21. Exceptions

Business needs, local laws, or regulations may require exceptions to this policy. Any exceptions will be approved by RAIA management and documented.

22. Changes to This Policy

We may update this Privacy Policy from time to time. Material changes will be communicated via email to registered users or through a prominent notice on our website. The "Last Updated" date at the top of this policy indicates when it was last revised. Continued use of our services after changes constitutes acceptance of the updated policy.

23. Contact Information

For questions about this policy, to exercise your data subject rights, or to request a Data Processing Agreement:

Privacy Contact:

Email: privacy@raiaai.com

General Support:

Email: support@raiaai.com

Phone: +1 941-300-0780

Mailing Address:

RAIA LLC

1751 Mound Street

Sarasota, FL 34236

United States

For EU/EEA residents, you have the right to lodge a complaint with your local supervisory authority if you believe your data protection rights have been violated.

Last Updated: May 8, 2026

These Terms and Conditions ("Terms") govern your access to and use of websites operated by RAIA LLC ("RAIA," "we," "us," or "our"), including raiabot.com, raiaai.com, and raiaagent.com (collectively, the "Site"), as well as the RAIA Launch Pad platform and related services (collectively, the "Services").

By visiting, accessing, or using any part of the Site or Services, you accept these Terms in full. If you disagree with any part of these Terms, you must not use the Site or Services.

1. Eligibility

You must be at least 18 years of age to use the Site or Services. By using them, you represent and warrant that you meet this requirement.

2. Cookies

This Site uses cookies as described in our Privacy Policy. By using the Site and agreeing to these Terms, you consent to our use of strictly necessary cookies. Non-essential cookies (analytics, marketing) are only placed with your explicit consent via our cookie consent mechanism, in accordance with the ePrivacy Directive and applicable laws.

3. Artificial Intelligence — Limitations, Risks, and Responsibility

Our AI platform uses large language models developed by OpenAI, including advanced LLM systems. While designed for accuracy, AI responses may be incomplete, inaccurate, biased, outdated, or otherwise unreliable.

3.1 AI Output Disclaimer

• RAIA LLC does not warrant the truth, accuracy, legality, or fitness of any AI-generated output.
• You are solely responsible for reviewing, validating, and determining the suitability of any AI output before using it.
• You will not represent AI outputs as factual without independent verification.
• You assume all risk for any consequences arising from your use, publication, or reliance on AI-generated content.

3.2 AI Risks (including but not limited to)

• Accuracy and reliability limitations
• Potential bias in outputs
• Security vulnerabilities
• Privacy concerns and regulatory compliance risks
• Over-reliance on automation
• Intellectual property issues
• Operational failures or outages
• Ethical considerations
• Limited interpretability or explainability
• Scalability issues

RAIA LLC disclaims all liability for damages or losses resulting from the use of AI-generated outputs.

3.3 AI Data Handling

• Customer data submitted to AI features is processed solely for the purpose of providing the requested service.
• RAIA does not use customer input data to train or improve AI models without explicit written consent.
• AI interaction data is retained in accordance with our Data Retention Policy and deleted upon contract termination.

4. Communications Consent (TCPA Compliance)

4.1 Express Written Consent

By submitting your contact information, you give express written consent to receive communications from RAIA LLC, its affiliates, subcontractors, and partners via:

• Email, calls, text messages (SMS/MMS)
• Pre-recorded/artificial voice messages
• Automatic dialing systems ("auto-dialers")

Standard carrier rates may apply.

4.2 No Purchase Required

You are not required to consent to promotional communications to use the Services. However, opting out of certain messages (e.g., security alerts) may affect functionality.

4.3 Frequency

Communication frequency may vary based on account activity and service needs.

4.4 Opt-Out

You may revoke consent at any time:

• Text: Reply "STOP" (immediate for SMS)
• Email: Click "Unsubscribe" (immediate for email)
• Phone: Call +1 941-300-0780 or email support@raiaai.com

Processing opt-outs via non-automated methods may take up to 30 days.

4.5 Service-Related Communications

Certain non-marketing communications (e.g., account alerts, legal notices, security notifications) may continue after opt-out as they are necessary for the provision of the Services.

5. Customer Compliance and Messaging Responsibility

Our platform allows you to send email, SMS/MMS messages, voice calls, and live chat messages. You are solely responsible for ensuring that your use of these features complies with all applicable laws, including but not limited to:

• The U.S. Telephone Consumer Protection Act (TCPA)
• CAN-SPAM Act
• GDPR and ePrivacy Directive (EU/EEA)
• CASL (Canada)
• State and local telemarketing or privacy laws
• Any applicable industry rules (e.g., CTIA guidelines for SMS)

You must:

• Obtain all legally required consents before sending any communication.
• Honor all opt-out requests promptly.
• Ensure your message content is lawful, truthful, and non-deceptive.
• Not use the platform to send spam, unlawful marketing, harassment, or other prohibited content.
• Maintain records of consent as required by applicable law.

6. Data Protection and Privacy

6.1 Privacy Policy

Your use of the Site and Services is governed by our Privacy Policy, which describes how we collect, use, store, and protect your personal data.

6.2 Data Processing Agreement

For customers who process personal data of EU/EEA residents through our platform, RAIA offers a Data Processing Agreement (DPA) in compliance with GDPR Article 28. The DPA includes:

• Standard Contractual Clauses (SCCs) for international data transfers
• Technical and organizational security measures
• Sub-processor management and notification procedures
• Data subject rights assistance obligations
• Breach notification commitments

To request a DPA, contact privacy@raiaai.com.

6.3 Customer Responsibilities as Data Controller

When using RAIA's platform to process personal data, you act as the data controller and are responsible for:

• Establishing a lawful basis for processing (e.g., consent, legitimate interest)
• Providing appropriate privacy notices to data subjects
• Responding to data subject rights requests (with RAIA's reasonable assistance)
• Conducting Data Protection Impact Assessments where required
• Ensuring compliance with all applicable data protection laws

6.4 RAIA's Obligations as Data Processor

When processing personal data on your behalf, RAIA will:

• Process data only on your documented instructions
• Ensure personnel are bound by confidentiality obligations
• Implement appropriate technical and organizational security measures
• Assist you in responding to data subject rights requests
• Notify you without undue delay of any personal data breach
• Delete or return all personal data upon termination of services
• Make available information necessary to demonstrate compliance

6.5 Sub-Processors

RAIA engages sub-processors to deliver certain aspects of the Services. A list of current sub-processors is available in our Privacy Policy and upon request. We will provide customers with advance notice of changes to sub-processors as specified in the DPA.

7. Security

7.1 Security Measures

RAIA implements and maintains appropriate technical and organizational measures to protect the confidentiality, integrity, and availability of customer data, including:

• Encryption of data in transit (TLS 1.2+) and at rest (AES-256)
• Role-based access controls and multi-factor authentication
• Regular security assessments and penetration testing
• Continuous monitoring and intrusion detection
• Employee security awareness training
• Documented incident response procedures

7.2 Compliance Certifications

RAIA maintains the following compliance certifications and attestations:

• SOC 2 Type II — Independently audited controls for security, availability, and confidentiality
• HIPAA — Compliance with the Health Insurance Portability and Accountability Act for customers handling protected health information
• GDPR — Compliance with the General Data Protection Regulation for processing EU/EEA personal data

7.3 Security Incident Notification

In the event of a confirmed security incident affecting customer data:

• RAIA will notify affected customers without undue delay (and within 72 hours where GDPR applies)
• Notification will include the nature of the incident, data affected, and remediation steps taken
• RAIA will cooperate with customers in meeting their own regulatory notification obligations

7.4 Right to Audit

Customers with a DPA in place may request evidence of RAIA's compliance with its security obligations. RAIA will make available:

• SOC 2 Type II audit reports
• Penetration testing summaries
• Compliance certifications
• Responses to reasonable security questionnaires

8. Service Availability

8.1 Uptime Commitment

RAIA targets 99.9% uptime for its production services, measured monthly. Current service status is available at the status page linked from our website.

8.2 Scheduled Maintenance

RAIA will provide reasonable advance notice of scheduled maintenance that may affect service availability. Where possible, maintenance will be performed during off-peak hours.

8.3 Force Majeure

Neither party shall be liable for failure to perform obligations due to circumstances beyond reasonable control, including natural disasters, acts of government, pandemic, war, terrorism, or widespread internet outages.

9. User Accounts, Content, and Intellectual Property

9.1 Your Content

"Your Content" includes any material you submit (text, images, audio, video, etc.). You grant RAIA LLC a worldwide, non-exclusive, royalty-free license to use, reproduce, adapt, and process Your Content solely for the purposes of providing the Services. This license terminates when you delete Your Content or terminate your account.

You must not submit illegal content or anything that infringes third-party rights. RAIA LLC reserves the right to remove or disable access to user content that violates these Terms.

9.2 Customer Data Ownership

You retain all rights, title, and interest in your data. RAIA does not claim ownership of customer data and will not access, use, or disclose customer data except as necessary to provide the Services or as required by law.

9.3 Our Content

Unless otherwise stated, RAIA LLC owns all intellectual property rights to the Site and its content. You may view, download (for caching), and print for personal, non-commercial use only. You must not republish, sell, rent, sub-license, publicly display, or exploit our content without written consent.

10. Acceptable Use

You must not:

• Damage, disrupt, or impair Site functionality
• Use the Site for unlawful, fraudulent, or harmful purposes
• Transmit malware or malicious code
• Conduct automated data scraping or harvesting without consent
• Send unsolicited commercial messages via the Site
• Use the Site for marketing without written consent
• Attempt to gain unauthorized access to any part of the Services
• Use the Services in a manner that violates any applicable law or regulation
• Process special categories of personal data (as defined under GDPR Article 9) without appropriate safeguards and RAIA's prior written consent

11. Dispute Resolution and Arbitration

11.1 Mandatory Arbitration

Any dispute relating to these Terms or the Services will be resolved by final and binding arbitration under JAMS or the AAA, before a single qualified arbitrator. Both parties waive the right to a jury trial.

11.2 Right to Opt-Out

You may opt out within 30 days of first accepting these Terms by sending written notice to:

RAIA LLC — Arbitration Opt-Out

support@raiaai.com

1751 Mound Street, Sarasota, FL 34236

11.3 Covered Claims

Includes, but is not limited to: billing disputes, data access issues, API failures, IP rights, breaches of contract, and compliance with laws.

11.4 Exceptions

• Small claims filed individually
• Government enforcement actions
• IP-related injunctive relief
• Disputes about the enforceability of this arbitration clause
• Data protection claims brought before a supervisory authority or competent court under GDPR (which cannot be subject to mandatory arbitration under EU law)

11.5 Class Action Waiver

All claims must be brought individually; no class or representative actions allowed.

11.6 Governing Law

This arbitration agreement and any disputes are governed by the Federal Arbitration Act and, where not inconsistent, Florida law.

Note for EU/EEA Residents: Nothing in this arbitration clause limits your right to lodge a complaint with a supervisory authority or bring proceedings before the courts of your habitual residence under GDPR Article 79.

12. Disclaimers and Limitations of Liability

The Site and Services are provided "as is" without warranties of any kind. RAIA LLC does not guarantee uninterrupted access, accuracy, or error-free operation.

To the fullest extent permitted by law:

• RAIA LLC is not liable for indirect, incidental, consequential, or punitive damages.
• RAIA LLC's total aggregate liability shall not exceed the fees paid by you in the twelve (12) months preceding the claim.
• Nothing in these Terms limits liability for death, personal injury, fraud, or other liability that cannot be excluded by law.

For EU/EEA Residents: These limitations apply only to the extent permitted by applicable EU/EEA law. Nothing in these Terms excludes or limits liability in a way that is not permitted under the laws of your country of residence.

13. Indemnification

You agree to defend, indemnify, and hold harmless RAIA LLC, its affiliates, officers, employees, and contractors from any claims, losses, damages, penalties, fines, or expenses arising from:

• Your use of AI-generated outputs
• Your sending of any communication through the platform
• Any alleged violation of spam, privacy, consumer protection, or telemarketing laws
• Any misuse of the platform or its features by you or anyone using your account
• Your content or account activity
• Your breach of these Terms or applicable laws
• Infringement of third-party rights
• Failure to obtain required consents for communications
• Your failure to comply with data protection obligations as a data controller

14. Right to Suspend or Terminate

RAIA LLC may suspend or terminate your access without notice if your use of the Services:

• Violates applicable laws or regulations
• Generates excessive spam complaints
• Creates a risk of legal liability or reputational harm to RAIA LLC
• Violates these Terms
• Poses a security risk to the Services or other users

Upon termination, RAIA will delete or return your data in accordance with the Data Retention provisions in our Privacy Policy and any applicable DPA.

15. Changes to Terms

We may update these Terms at any time by posting the revised version on the Site. For material changes, we will provide at least 30 days' advance notice via email or prominent notice on the Site. Continued use after the effective date constitutes acceptance. If you do not agree to the updated Terms, you must stop using the Services.

16. Assignment

We may transfer or sub-contract our rights and obligations under these Terms without notice, provided the assignee agrees to be bound by these Terms. You may not assign your rights without our written consent.

17. Severability

If any provision is unenforceable, the remaining provisions remain in effect. The unenforceable provision will be modified to the minimum extent necessary to make it enforceable while preserving its intent.

18. Entire Agreement

These Terms, together with our Privacy Policy and any applicable DPA or service-specific agreements, constitute the full agreement between you and RAIA LLC regarding the Site and Services, superseding all prior agreements.

19. Governing Law and Jurisdiction

These Terms are governed by Florida law. Any non-arbitrable disputes will be heard exclusively in the state or federal courts of Sarasota County, Florida.

For EU/EEA Residents: If you are a consumer residing in the EU/EEA, you may also bring proceedings in the courts of your country of habitual residence. Nothing in these Terms affects your rights as a consumer under mandatory provisions of the law of your country of residence.

20. Contact Information

For questions about these Terms:

General Support:

Email: support@raiaai.com

Phone: +1 941-300-0780

Privacy and Data Protection:

Email: privacy@raiaai.com

Mailing Address:

RAIA LLC

1751 Mound Street

Sarasota, FL 34236

United States