Security and incident response

DeltaSys holds schedules, estimates, rates and costs that are commercially sensitive. This page states, in plain terms, what we do to protect them, how we respond when something goes wrong, and what we ask of you. It is a description of practice, not a contract; the terms of use govern.

1Scope

This page covers the DeltaSys website, the Planner, Estimator and Time Control applications, the API behind them, and the shared instance at deltasys.app. A dedicated (Enterprise) instance follows the same practice on its own server, with the differences agreed in its order form.

2Where it runs

• The service is hosted on Akamai Cloud (Linode) in Toronto, Canada. Backups are kept in Akamai object storage in Chicago, encrypted before they leave the server.
• Only HTTPS is served. The site is on the browser preload list for HTTP Strict Transport Security, so a browser never attempts a plain connection.
• Every page carries a content security policy and the standard browser defences (no MIME sniffing, no framing by other sites, a tight referrer policy, no access to camera, microphone, location or payment APIs).
• Servers expose only SSH (keys only, no root password, automatic blocking of repeated failures), 80 and 443. Operating-system security updates install automatically.

3Encryption

• In transit: TLS 1.2 or better between your browser and the service, and between the service and every provider it talks to (Stripe, Microsoft, the mail service). Email we send is signed (DKIM) and delivered over TLS where the receiving server supports it.
• At rest: server disks are encrypted (AES, managed by the hosting provider). Backups are encrypted with a separate key before upload.
• Secrets: passwords are stored as salted scrypt hashes; password-reset tokens and recovery codes as SHA-256 hashes; authenticator secrets and the credentials of the connections you set up (Workday, JDE, SAP and the rest) are encrypted with AES-256-GCM under a key that lives only on the server.
• Cards: payment details go straight to Stripe. DeltaSys never sees or stores a card number.

4Identity and access

• Sign in with a password, a passkey (fingerprint, face or PIN on your own device; it cannot be phished), or Microsoft single sign-on. An authenticator app can be added as a second factor; a workspace administrator can require a second factor, or Microsoft sign-in from a named tenant, for everyone in the workspace.
• Sessions are cookie-based (HttpOnly, Secure, SameSite), expire after 30 days, are listed under Profile and security, and can be revoked from any browser. Changing a password or completing a reset signs out every other browser.
• Roles are owner, admin, planner, viewer and executive. Viewers and executives are read-only. Billing and ownership changes need an owner.
• Workspace API keys and webhooks are scoped to one workspace; outbound webhooks are signed; inbound ones are verified with a shared secret.
• Access by DeltaSys staff to customer data is limited to what support or operations requires, and happens only through the server or an account the workspace has invited.

5Monitoring and logging

• Each workspace has an audit log of sign-ins, role changes, invitations, single sign-on and second-factor settings, project deletions and connection runs, visible to its administrators and included in the workspace export.
• Errors raised in your browser are reported to us without project content (the message, the code location and the release), so faults are seen before they are reported.
• Server, mail and connection activity is logged on the server and in our Microsoft 365 tenant; logs are reviewed when an alert or a report calls for it.

6Backups and continuity

• Nightly encrypted backups of the database and keys, kept for 7 daily, 5 weekly and 12 monthly generations, in a different region from the server; a restore is tested every week. The hosting provider's own disk snapshots run as well.
• Your projects are also kept in your browser (local first) and can be exported at any time as files you own (.planner.json, XER, Microsoft Project XML, CSV, PDF), so a service outage does not stop work in progress.
• Recovery objective: the service restored from the latest backup within a working day; data loss limited to changes made since the last nightly backup.

7Vulnerability management

• Every release passes an automated gate before it reaches staging and then production: unit tests, several hundred browser checks, a dependency vulnerability audit, and a walk of every page with the security headers enforced.
• Third-party packages are pinned and audited at each release; a vulnerable dependency blocks the release until it is updated or mitigated.
• Operating-system patches install automatically; the runtime (Node.js) and the reverse proxy are updated with releases.

8Incident response

A security incident is any event that compromises, or may have compromised, the confidentiality, integrity or availability of customer data. When one is detected or reported:

1. Contain within hours: revoke exposed credentials or sessions, isolate or take the affected component offline, block the source.
2. Assess what was affected, which workspaces, what data, and for how long, from the audit and server logs.
3. Notify the administrators of affected workspaces without undue delay and in any case within 72 hours of confirming a breach of personal information, with what happened, what data was involved, what we have done and what you should do. Where the law requires it (for example PIPEDA in Canada), the regulator is notified as well.
4. Recover: restore from backup where data was altered or lost, rotate keys and secrets, confirm the fix in staging before production.
5. Review within two weeks: a written post-incident report with the root cause and the changes made, shared with affected customers on request.

9Reporting a vulnerability

If you believe you have found a security weakness in DeltaSys, email info@deltasys.app with "Security report" in the subject. Give us enough to reproduce it and a way to reach you. We acknowledge reports within two working days, keep you informed, and do not take action against good-faith research that avoids privacy violations, data destruction and service disruption, and that does not access data beyond what is needed to demonstrate the issue. Do not test against other customers' workspaces.

10Data retention

• Workspace data (projects, estimates, enterprise setup, connections, audit log) is kept while the workspace exists. When an owner deletes a workspace, or an account is closed, its data is deleted from the live database at once and ages out of backups within 12 months.
• Account data (name, email, sign-in methods, sessions) is kept while the account exists and deleted with it; sessions expire after 30 days of inactivity.
• Billing records are kept for seven years, as Canadian tax law requires, at Stripe and in our accounts.
• Logs (server, audit, error reports, mail traces) are kept for 12 months unless an investigation needs them longer.
• Contact-form messages are kept for two years.

The privacy notice has the same schedule for personal information and your rights over it.

11Subprocessors

The providers that handle customer data on our behalf: Akamai Cloud / Linode (hosting and backups, Canada and the United States), Stripe (payments), Microsoft 365 (transactional email, single sign-on; Canada), Anthropic (the optional in-app assistant: when you ask it something, your question and a text summary of the open project or portfolio are sent to answer it, and nothing is sent until you ask), and Slack (internal alerting of contact-form messages, no project data). We tell workspace administrators before adding a subprocessor that would handle project data.

12Your part

• Use a passkey or an authenticator app, and require one for your workspace if it holds financial data. Prefer Microsoft single sign-on where your organisation has it, so leavers lose access when their account is disabled.
• Give people the least role they need; viewers and executives are free and read-only.
• Keep your own exports of critical projects, and tell us at once if you suspect an account or an API key has been compromised.

13Independent assurance

DeltaSys has not yet been audited under SOC 2 or ISO 27001. An independent penetration test and a SOC 2 Type I report are planned; this page will say when they are complete, and Enterprise customers may request the results under NDA. Until then, the practices above are our own statement, and we will answer a security questionnaire for any prospective customer.

14Contact

Security questions, questionnaires and reports: info@deltasys.app. PGR Delta Systems Corp., Ontario, Canada.