Protecting union information
Union work can involve sensitive personal information and confidential case records. Security at UnionOps depends on the application, the organization operating the service, and the people using it. This statement explains those responsibilities and the limits of the protections described here.
It covers the public communications tools, Officer Hub, and Local Portal. A separately operated installation may use different storage, service providers, and security settings. Ask its operator which protections are enabled and verified.
Where your work is stored
Public communications tools process graphics and member photos in your browser. Those tools do not upload the photos to UnionOps merely because you add them to a design. Browser-saved drafts and downloaded files still need protection on your device. Sending, publishing, or explicitly saving content to a hosted feature changes where that content is held.
Officer Hub and Local Portal use the server operated for that installation. Hosted records and attachments should be treated as confidential information entrusted to that operator. Public website use can also generate technical logs or error reports; on-device editing does not mean that every interaction with the website stays on your device.
Access and separation between unions
Officer Hub access is invitation-based. Application permissions use the person’s union, local, role, and relevant assignment to determine which records and actions are available. Belonging to one union does not authorize access to another union’s confidential records.
Privileged operational functions are distinct from ordinary member or officer access. Some support and administration functions require carefully controlled access across organizational boundaries. These functions must not be understood as permission for unrestricted browsing of case files.
The application supports database-level restrictions as an additional safeguard. Their effectiveness depends on correct production configuration and verification. No access-control design can justify a guarantee that unauthorized access is impossible.
Signing in and sensitive actions
UnionOps-operated hosted customer deployments require multi-factor authentication for privileged access. The required method uses time-based codes from an authenticator app. Selected sensitive actions, such as changing authority or exporting confidential information, require a fresh verification.
This requirement does not mean that every basic member account must use multi-factor authentication for every permitted activity. Separately operated installations are responsible for setting and verifying their own authentication policy.
Use an individual account, keep recovery codes private, and contact the operator promptly if you believe your account is compromised. UnionOps support should never need your password, authenticator code, or recovery codes in an email.
Encryption and its limits
Hosted connections use HTTPS to protect information while it travels between your browser and the service. HTTPS does not, by itself, encrypt stored records or protect a file after it has been downloaded.
Officer Hub case records and attachment contents are not generally encrypted by the application before storage. Protection of stored information depends on the host’s database, disk or storage-service encryption, access controls, and key management. The application has separate protection for authenticator secrets when the required encryption configuration is present; that protection does not extend to all casework.
UnionOps does not describe hosted casework as end-to-end encrypted. Authorized server-side processing requires access to the information.
For supported hybrid exports, the browser encrypts the export with a passphrase that remains in the browser. The selected data first travels from the server to the browser over the authenticated HTTPS connection. Attachments and other hosted features do not automatically become local or encrypted by that passphrase. Protect the export and keep its passphrase separately.
Uploads, monitoring, and maintenance
The application includes file validation, configurable malware scanning, security event records, and development checks intended to identify vulnerable dependencies and other defects. These controls have different scopes and depend on the deployed version and configuration. A scanner cannot guarantee that every harmful file will be detected.
Operators may enable technical error reporting to investigate failures. Error reporting is separate from product analytics and from the security audit record. Reports should exclude passwords, authentication tokens, and confidential case content. The explains the related data handling.
Production operation also requires maintained systems, appropriate backups, restoration testing, and a way to receive and act on alerts. The existence of these capabilities in the software does not establish that a particular host has successfully tested them. This statement promises no specific recovery time, zero data loss, independent certification, or uninterrupted service.
Report a security concern
Report suspected vulnerabilities, exposed information, or account compromise privately to ryan@ryanmorris.ca, with “Security” in the subject line. You may write in English or French.
Include the affected page or feature, an approximate time and time zone, and a short description of what happened. For a suspected vulnerability, include the minimum steps needed to explain it. Use test information wherever possible and remove personal data and secrets from evidence.
Do not email passwords, recovery codes, confidential case files, or unnecessary copies of exposed information. If sensitive evidence is essential, ask how to transfer it securely first. A report does not authorize testing another person’s account, accessing additional records, disrupting the service, or conducting a broader security test.
Responding to incidents
Our incident-response process is to assess the report, contain the issue, establish which information and people may be affected, and coordinate corrective action with the responsible organizations. Any required notice to customers, affected individuals, or regulators depends on the incident, applicable law, and contractual obligations.
Where Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) applies and a breach creates a real risk of significant harm, reporting and individual notification are required as soon as feasible. There is no universal 72-hour PIPEDA notification rule. See the federal Privacy Commissioner’s breach guidance.
Review and related information
We will revise this statement when material changes affect the security information provided here. Any service-specific contractual commitments should be read in the applicable agreement.