Compliance Guide

This page gives an overview of how the solution can help organizations comply with various certification or standards.

All information contained in the files transferred with the solution is encrypted according to the principle outlined in the cryptographic architecture of the solution.

ISO 27001

OKIOK's S-Filer Portal SaaS offering is certified ISO 27001 and its certificate is available upon request.

As part of this certification, all controls related to OKIOK's development and release process for the solution were audited.

SOC 2 Type 2

OKIOK does not have aSOC 2 Type 2 report for its S-Filer Portal SaaS offering but has them for RAC/M Identity and OKIOK MDR. However, all corporate processes as well as development and release practices are the same across all of OKIOK's solutions so the controls audited as part of these reports are based on evidences that applies to S-Filer Portal as well.

The SOC 2 Type 2 reports can be made available to clients at OKIOK's discretion.

PCI-DSS

The solution is a generic file transfer solution. As such, it does not directly keep cardholder data. However, it is possible to use the solution to exchange files containing cardholder data. The solution can enforce policies to encrypt all files using AES256 keys and RSA keys of sufficient length (2048, 4096 or longer) to comply with PCI-DSS requirements. Further, the solution allows clients to configure key expiration and rotation according to policies that comply with PCI-DSS requirements.

If a client needs to be certified, here is a non-exhaustive list of requirements that the client has the responsibility to comply with:

• Encryption algorithms and key lengths
• Key lifetimes and rotation parameters
• Only authorized personnel has access to the S-Filer database and that they sign key custodian forms

Data privacy requirements (GDPR, PIPEDA, Quebec Law 25, etc.)

Once again, all personally identifiable information (PII) in file contents is encrypted according to the policies in the system. By default these policies dictate that all data is encrypted and therefore protected when residing in the solution.

However, the solution collects some user information for the purpose of transferring files.

1. Account name: This can be any unique identifier. Clients can choose to create accounts using any nomenclature for account names. However, when using the "shares" feature of the solution and inviting guest users into shares, the account name matches the entered email address (see email below).
2. Name: This is usually the user's name. Depending on jurisdictions, regulations and circumstances it could be considered PII. This is field is mandatory but it could contain any value and does not need to be unique. It is only used in the web interface to identify the logged in account and to personalize email notifications. If this field causes an issue, initials could be entered in this field or a static strings such as "Unavailable for privacy reasons"
3. Email Address: The email address is used in the solution for mail notifications or as a mechanism to recover a forgotten password. The email address is also used as the account identifier for guests accounts created in "shares".
4. IP address: In some jurisdictions/regulations, IP addresses are considered PII. S-Filer collects IP addresses in its audits and logs for security monitoring purposes to prevent attacks by malicious actors (ex: brute force, DoS).
5. Phone number: This field is optional for users and is opt-in, so only users who want to use SMS as an MFA mechanism and consent enter their phone number in the solution. There is one exception when a user performs a "quick send" to a guest user outside the platform and wants to authenticate the transfer using the SMS and the recipient's phone number. In that case, the solution requires that the sender get consent from the recipient and records the sender's confirmation before allowing the transfer.

The solution can display a consent screen on login where users must consent to the solution using their information, minimally their email and IP address. If the user does not consent, they cannot use the solution and the session is ended.

Cookies

The solution uses a few cookies to work properly. They do not contain PII and are used exclusively by the solution to provide functionality.

Here is a list of the various cookies and their content and purpose:

• JSESSIONID: This is a random string used to identify the user session on the server. This is how the web server "knows" who the user is once they are authenticated.
• SFILER_COOKIE, SFILER_THEME: These are convenience cookies used on the login page. They hold the last used language, authentication domain and theme that the user had when they last used the application. They are mainly for convenience so that the user does not have to change the language or authentication domain each time they get to the login page.
• toggleStates: This is another convenience cookie used in the administration screens. These screens have several collapsible sections and this cookie remembers the state of each so that re-opening the same page already has the sections expanded or collapsed according to user preferences.
• SFILER_MFA_LONG_LIVED_TOKEN_COOKIE: When a user selects "Remember me on this device" after performing an MFA authentication, this cookie is stored on the device to "remember" the fact that MFA was already done. By default this cookie is stored for 168 hours (1 week).
• OpenIdConnect: This cookie is only used during an OpenID connect authentication. When sending the user to the OpenID Connect authentication provider (e.g. Google, Microsoft, Salesforce, etc.), this cookie holds a state and some information necessary to validate the response and process it correctly.