Information Security Policy

Effective Date: May 3, 2026  ·  Version 1.2

Emmber, Inc., a Delaware corporation qualified to do business in the State of Florida, which operates the Pluse platform at pluse.to and the Pluse iOS application available on the Apple App Store (“Emmber,” “Pluse,” “we,” “us,” or “our”), is committed to protecting the security of your data. This Information Security Policy describes the technical and organizational measures we implement across the Pluse web platform and the Pluse iOS application (collectively, the “Service”).

“Pluse” is the consumer brand and product name under which Emmber, Inc. provides the Service; “Emmber, Inc.” is the legal entity. References in this Policy to either “Emmber” or “Pluse” identify the same legal entity. Security inquiries, vulnerability reports, and incident notices received under either name are handled by Emmber, Inc.

This policy is provided for transparency and applies to all users of the Service. For information about how we collect and use your data, please refer to our Privacy Policy. For the terms governing your use of the Service, see our Terms of Service.

1. Scope

This policy covers the security measures applied to:

• Pluse Web Platform — the business management application accessible at pluse.to, including invoicing, time tracking, expense management, client management, and AI-assisted features.
• Pluse AI iOS Application — the native iOS application available on the Apple App Store, providing mobile access to Pluse features including biometric authentication, receipt scanning, time tracking, and contactless payments via Tap to Pay on iPhone.
• Pluse API — the backend services that power both the web platform and iOS application.

2. Governance & Risk Management

2.1 Information Security Program

Pluse maintains a Written Information Security Program (WISP) in compliance with 201 CMR 17.00 (Massachusetts Standards for the Protection of Personal Information). The WISP designates the CEO as the responsible officer for information security, establishes administrative, technical, and physical safeguards, and is reviewed and updated at least annually or upon any material change to business operations or data processing practices.

2.2 Risk Identification

Pluse identifies information security risks through the following mechanisms:

• Continuous error monitoring: Sentry (application performance monitoring) is integrated into the production environment to detect runtime errors, unhandled exceptions, and anomalous behavior in real time.
• Automated security updates: The production server runs Ubuntu with unattended-upgrades enabled, automatically applying security patches for operating system packages.
• Dependency review: Third-party dependencies (PHP via Composer, JavaScript via npm) are periodically reviewed for known vulnerabilities.
• Code review: All code changes are reviewed before deployment to production through the git-based deployment workflow.
• Known issues tracking: A maintained internal log tracks identified security issues, technical debt, and remediation status.

2.3 Risk Mitigation

Identified risks are mitigated through a combination of technical controls (encryption, access control, input validation), organizational controls (code review, deployment procedures, personnel access management), and third-party controls (delegating payment processing to PCI-certified providers, delegating bank authentication to Plaid). Risks are prioritized by potential impact to consumer data and business operations.

2.4 Risk Monitoring

Security posture is monitored through:

• Real-time alerting: Sentry generates alerts for application errors and exceptions, including potential security events.
• Security event logging: Authentication attempts, rate limit violations, and access control events are logged and retained for 30 days.
• Audit logging: Security-relevant actions (account creation, deletion requests, permission changes) are logged with timestamps, IP addresses, and user identifiers.
• Third-party monitoring: Stripe, Plaid, and QuickBooks provide their own security monitoring dashboards and alerting for integration-level anomalies.
• Annual review: The WISP, this policy, and all security controls are reviewed at least annually and updated as needed.

3. Data Encryption

3.1 Encryption in Transit

All data transmitted between your device and our servers is encrypted using TLS (Transport Layer Security). Our iOS application enforces App Transport Security (ATS), which requires HTTPS for all network connections. Plaintext HTTP connections are not permitted in production.

3.2 Encryption at Rest

Sensitive data stored in our database is encrypted using AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode), an authenticated encryption algorithm that provides both confidentiality and integrity verification. The following categories of data are encrypted at rest:

• Tax identification numbers (EIN, SSN, Tax ID)
• Bank account and routing numbers
• Payment method tokens
• Third-party OAuth access and refresh tokens (QuickBooks, Plaid)

Encryption keys are derived using HKDF (HMAC-based Key Derivation Function) with SHA-256. Each encryption operation uses a unique initialization vector and produces an authentication tag to detect tampering.

4. Authentication & Access Control

4.1 Password Security

User passwords are hashed using bcrypt with a work factor calibrated to current industry guidance, a deliberately slow hashing algorithm designed to resist brute-force attacks. We enforce a minimum password length and require a mix of uppercase letters, lowercase letters, numbers, and special characters. Passwords are never stored in plaintext.

Our login system includes timing-based enumeration protection — authentication requests for non-existent accounts are processed with dummy hash verification to prevent attackers from determining whether an email address is registered.

4.2 Token-Based Authentication

After successful authentication, the Service issues a JSON Web Token (JWT) signed with a secure HMAC algorithm. Tokens include an expiration claim and are validated on every API request. The signing secret is stored securely as an environment variable.

4.3 Social Sign-In

We support Sign in with Apple and Google Sign-In as alternative authentication methods. Social sign-in tokens are validated server-side against the respective provider’s public keys before granting access. We verify the token audience, issuer, and expiration claims.

4.4 Biometric Authentication (iOS)

The Pluse AI iOS application supports Face ID and Touch ID for convenient, secure authentication. Biometric credentials are managed through the iOS Keychain with the following protections:

• Access Control: Biometric data is gated by BIOMETRY_CURRENT_SET, meaning stored credentials are invalidated if the device’s biometric enrollment changes (e.g., a new fingerprint is added).
• Device Binding: Keychain items are stored with WHEN_PASSCODE_SET_THIS_DEVICE_ONLY accessibility, ensuring credentials cannot be extracted from device backups or transferred to other devices.
• Failure Lockout: After a small number of consecutive biometric failures, biometric authentication is temporarily disabled and the user must re-authenticate with their password.

4.5 Session Management (Web)

Web sessions are configured with the following security settings:

• HttpOnly cookies: Session cookies cannot be accessed by client-side JavaScript, mitigating cross-site scripting (XSS) attacks.
• Secure flag: Cookies are only transmitted over HTTPS in production.
• SameSite=Lax: Cookies are not sent on cross-origin requests, mitigating cross-site request forgery (CSRF).
• Session timeout: Sessions expire after a period of inactivity.
• Session rotation: Session IDs are regenerated periodically to reduce the window of exposure for session fixation attacks.
• Session fingerprinting: Sessions are bound to the client’s User-Agent and Accept-Language headers to detect session hijacking.

5. Personnel Security

5.1 Access Provisioning

Access to production systems, databases, and third-party integrations is provisioned on a need-to-know basis following the principle of least privilege. Each authorized individual receives unique credentials — shared accounts are prohibited.

5.2 Production Access

Production server access is restricted to SSH public key authentication. Password-based SSH authentication is disabled. SSH keys are unique per individual and are revoked immediately upon role change or departure.

5.3 Third-Party Platform Access

Access to third-party platforms that store or process consumer financial data (Stripe, Plaid, QuickBooks, DigitalOcean, Sentry) is protected by multi-factor authentication (MFA) at the platform level. Each platform account uses unique credentials with MFA enabled.

5.4 Access Review

Access privileges are reviewed when personnel roles change and at least annually. Accounts for individuals who no longer require access are deactivated promptly.

5.5 Acceptable Use

All personnel with access to production systems or consumer data are expected to:

• Use strong, unique passwords for all accounts
• Enable MFA on all third-party platforms
• Never share credentials or access tokens
• Report suspected security incidents immediately
• Follow the git-based deployment workflow for all code changes

6. Payment Security

6.1 Stripe Integration

All payment processing is handled by Stripe, a PCI DSS Level 1 certified payment processor. Pluse does not collect, store, process, or transmit raw credit card numbers, CVVs, or full card data on our servers. Payment information is submitted directly from the client to Stripe’s servers using Stripe Elements, and only tokenized references are stored in our database.

6.2 Webhook Verification

Incoming Stripe webhooks are verified using Stripe’s webhook signature verification before processing. This ensures that webhook payloads originate from Stripe and have not been tampered with in transit.

6.3 Stripe Connect

Merchant onboarding is handled through Stripe Connect Express accounts. Pluse does not have direct access to merchant bank account details — all payout and verification information is managed by Stripe.

7. API Security

7.1 Rate Limiting

All API endpoints that accept user input or initiate authenticated actions are protected by rate limiting to prevent brute-force attacks and abuse. Authentication endpoints (login, registration, password reset, social authentication) and general API requests are subject to per-IP and per-account limits, and repeated violations trigger progressive lockout with block durations that increase on each subsequent offense.

7.2 CORS (Cross-Origin Resource Sharing)

Our API uses a strict CORS whitelist. Only requests originating from authorized domains (pluse.to and our mobile application origins) are permitted. Wildcard origins are not allowed.

7.3 CSRF Protection

Web forms are protected with single-use CSRF tokens that expire after a short window. Token-based API requests (using Bearer JWT authentication) are inherently protected against CSRF, as authorization headers cannot be set by cross-origin requests from malicious sites.

7.4 Security Headers

All responses include the following security headers:

• X-Frame-Options: DENY — prevents the page from being embedded in iframes (clickjacking protection).
• X-Content-Type-Options: nosniff — prevents browsers from MIME-sniffing responses.
• X-XSS-Protection: 1; mode=block — enables browser-level XSS filtering.
• Referrer-Policy: strict-origin-when-cross-origin — limits referrer information sent to external sites.
• Content-Security-Policy — restricts the sources from which scripts, styles, and other resources can be loaded.

7.5 Input Validation

All user input is validated and sanitized before processing. We enforce maximum length limits on all input fields and restrict file uploads to approved MIME types (images, PDFs, and standard document formats) with a defined maximum file size. Database queries use parameterized prepared statements exclusively to prevent SQL injection.

8. Mobile Application Security

8.1 App Transport Security (ATS)

The Pluse AI iOS application enforces Apple’s App Transport Security, which requires all network connections to use HTTPS with modern TLS versions. Arbitrary plaintext HTTP connections are disabled (NSAllowsArbitraryLoads: false).

8.2 Secure Credential Storage

Authentication tokens on iOS are stored in the device Keychain, Apple’s hardware-backed secure storage. Keychain items are configured as device-only (not synced to iCloud or included in backups) and require the device passcode to be set.

8.3 Permissions

The Pluse AI iOS application requests only the permissions necessary for its features:

All permissions are requested at the time of use (not at install) and can be revoked at any time through iOS Settings.

8.4 App Store Distribution

The Pluse AI iOS application is distributed exclusively through the Apple App Store and undergoes Apple’s App Review process. The application is code-signed by Apple and verified on launch by iOS.

9. Data Storage & Retention

9.1 Database Security

Our database uses the following security configurations:

• Strict SQL mode enabled to prevent silent data truncation and invalid data insertion.
• Prepared statements with real (non-emulated) parameter binding to prevent SQL injection.
• UTF-8 encoding (utf8mb4) to prevent character-encoding-based attacks.
• Principle of least privilege — application database accounts have only the permissions necessary for normal operations.

9.2 Data Retention & Deletion

When you request account deletion, we implement a 30-day grace period during which your account is soft-deleted and can be restored if the request was made in error. After the 30-day period, your data is permanently and irreversibly removed from our systems. You may cancel a deletion request at any time during the grace period.

For complete details on data retention, including specific data categories and retention periods, please refer to our Data Retention Policy and Privacy Policy.

9.3 Sensitive Data Classification

We classify data into sensitivity tiers and apply encryption accordingly:

10. Third-Party Integrations

Pluse integrates with the following third-party services. All integrations use industry-standard OAuth 2.0 authentication flows, and all stored tokens are encrypted with AES-256-GCM before being written to our database.

10.1 Stripe (Payment Processing)

Stripe handles all payment card processing and merchant onboarding. Pluse communicates with Stripe’s API using server-side secret keys that are never exposed to client-side code. Webhook payloads are verified using Stripe’s signature verification. Stripe is PCI DSS Level 1 certified.

10.2 Plaid (Bank Account Linking)

Plaid provides secure bank account linking for transaction feeds. Users authenticate with their financial institution directly through Plaid’s interface — Pluse never sees or handles bank login credentials. Plaid exchanges temporary public tokens for persistent access tokens, which are encrypted before storage.

10.3 QuickBooks Online (Accounting Sync)

QuickBooks integration uses Intuit’s OAuth 2.0 flow with PKCE (Proof Key for Code Exchange). Access and refresh tokens are encrypted at rest. Token refresh is handled automatically to maintain sync without requiring users to re-authenticate.

10.4 AI Services

Pluse’s AI assistant (Lux) is powered by third-party AI models. Prompts and responses are transmitted over encrypted connections. We do not use your data to train AI models. For details on AI data handling, see our Privacy Policy.

11. Infrastructure & Network Security

11.1 Transport Security

All connections to pluse.to are served over HTTPS with TLS 1.2 or higher. Plaintext HTTP requests are redirected to HTTPS. HSTS (HTTP Strict Transport Security) is enabled with a max-age of one year, including subdomains, ensuring browsers always connect over HTTPS.

11.2 Network Architecture

The production environment is hosted on DigitalOcean cloud infrastructure. The application server runs behind Cloudflare, which provides DDoS protection, WAF (Web Application Firewall) capabilities, and TLS termination. Database access is restricted to localhost connections only — the database server does not accept remote connections.

11.3 Maintenance Mode

In the event of a security incident or critical maintenance, we can promptly restrict access to the platform through our maintenance mode system, preventing data exposure while the issue is resolved.

12. Security Monitoring & Logging

12.1 Application Monitoring

Sentry is integrated into the production environment for real-time error tracking and performance monitoring. Sensitive fields (passwords, tokens, API keys, access tokens, refresh tokens) are automatically filtered from error reports before transmission.

12.2 Security Event Logging

The following security events are logged with timestamps, IP addresses, and user identifiers:

• Successful and failed authentication attempts
• Rate limit violations and progressive lockouts
• Account creation and deletion requests
• Password changes and password reset requests
• OAuth token exchanges and refresh operations
• Bank account connections and disconnections
• Subscription changes and payment events

12.3 Log Retention

Security event logs and application error logs are retained for a defined period appropriate to their use, with longer retention for audit logs related to financial operations as required by IRS record-keeping rules. For complete retention periods, see our Data Retention Policy.

13. Change Management

13.1 Deployment Pipeline

All code changes follow a git-based deployment workflow:

1. Local development: Changes are developed and tested in a local environment.
2. Code review: Changes are reviewed before being committed to the main branch.
3. Syntax validation: PHP and JavaScript files are validated for syntax errors before deployment to prevent application-breaking changes.
4. Version control: All changes are committed to a private GitHub repository with full history and attribution.
5. Production deployment: Changes are deployed via SSH-authenticated git pull on the production server. Direct file uploads are prohibited.
6. Cache invalidation: Asset version numbers are incremented to ensure clients receive updated files.

13.2 No Direct Production Access

Production files are never modified directly on the server. All changes flow through version control, ensuring a complete audit trail and the ability to roll back any change.

14. Incident Response

In the event of a security incident that affects your data, we will:

1. Contain the incident immediately by isolating affected systems.
2. Investigate the scope and nature of the incident.
3. Notify affected users without unreasonable delay and no later than required by applicable law (including 72 hours under GDPR where applicable, and within timeframes required by applicable U.S. state breach notification laws).
4. Remediate the underlying vulnerability to prevent recurrence.
5. Document the incident and review our security measures.

Notifications will include a description of the incident, the types of data involved, the steps we are taking, and recommended actions you can take to protect yourself.

15. Business Continuity

15.1 Data Backups

Database backups are performed on a regular schedule and retained on a rolling basis. Backups are stored separately from the production database. Backup restoration procedures are documented and tested periodically.

15.2 Service Dependencies

Critical service dependencies (Stripe for payments, Plaid for bank connectivity, Cloudflare for DNS and CDN) are monitored for availability. The application is designed to degrade gracefully if a third-party dependency is temporarily unavailable — core functionality continues to operate while integration-dependent features display appropriate status messages.

15.3 Recovery Procedures

In the event of a service disruption, recovery follows these priorities:

1. Data integrity: Ensure no data loss or corruption has occurred.
2. Authentication: Restore login and session management.
3. Core operations: Restore invoicing, expense tracking, and time tracking.
4. Integrations: Restore Stripe, Plaid, and QuickBooks connectivity.
5. AI features: Restore AI assistant functionality.

16. Vulnerability Reporting

We value the work of security researchers and welcome responsible disclosure of vulnerabilities. If you discover a security issue in the Pluse platform or iOS application, please report it to:

• Email: support@pluse.to

When reporting a vulnerability, please include:

• A description of the vulnerability and its potential impact.
• Detailed steps to reproduce the issue.
• Any relevant screenshots, logs, or proof-of-concept code.
• Your preferred method of contact for follow-up.

We ask that you:

• Give us reasonable time to investigate and address the issue before public disclosure.
• Avoid accessing or modifying other users’ data.
• Act in good faith to avoid disruption to our services.

17. Policy Updates

We may update this Security Policy from time to time to reflect changes in our security practices, technology, or legal requirements. When we make material changes, we will update the “Effective Date” and version number at the top of this page. We encourage you to review this policy periodically.

For questions about this Security Policy, contact us at support@pluse.to.

Emmber, Inc. is a Delaware corporation qualified to do business in the State of Florida. The “Pluse” name and the Pluse platform are operated by Emmber, Inc.

© 2024–2026 Emmber, Inc. All rights reserved. Pluse™ and Lux™ are trademarks of Emmber, Inc.