Security Statement

Each Workspace is a tenant boundary and the separation between Workspaces is the most important control in the Service.

• The Workspace a request belongs to is derived on the server from the authenticated session. The browser cannot choose it, and a Workspace identifier sent by a client is never trusted.
• Every database query that reads Workspace data carries the Workspace condition, including across joins, so a join cannot widen the boundary.
• A record whose Workspace cannot be resolved is invisible rather than shared. The boundary fails closed.

• Passwords are stored only as a salted hash. They are never stored or logged in a readable form, and NotiSynk cannot read your password.
• A new account must confirm its email address before the Workspace becomes usable.
• Sessions use a short-lived access token together with a refresh token that is stored hashed on the server, so a stolen database row cannot be replayed as a session.
• The refresh cookie is set by the server, marked httpOnly so page scripts cannot read it, restricted to the sign-in path, sent only over a secure connection, and constrained by a same-site rule.
• A session lasts up to 12 hours, or 30 days where Remember me was chosen. Signing out ends it and revokes the refresh token.
• Reusing a refresh token that has already been used revokes every session for that account, so a stolen token cannot be used quietly alongside the real one.

• Roles are enforced on the server. A route guard in the browser is a convenience for the interface and is never treated as the control.
• Administrative access is limited to a small number of people and is used to operate, support and secure the Service.
• The people with access are bound by confidentiality obligations that continue after their engagement ends.

• Legal acceptance evidence, revenue transactions and session events are append-only. An entry is never edited or deleted, so a history cannot be rewritten after the fact.
• Database constraints enforce the rules that matter at the storage layer rather than relying only on application code.
• Payment and billing operations are idempotent, so a retried or duplicated request does not produce a second charge or a second record.
• Incoming provider webhooks are verified against the provider's signature before they are acted on, and are processed durably with retries so a transient failure does not silently lose an event.

• NotiSynk never receives, stores or transmits a complete payment-card number or a card security code. Card details go to the payment provider, and NotiSynk holds only the safe descriptive fields it returns: type, brand, last four digits and expiry.
• Provider credentials and signing secrets are supplied to the application through its configuration and are not exposed to the browser.
• Tokens used for email verification and password reset are stored as hashes and expire.

• Traffic to authentication and other sensitive endpoints is rate limited, and the limiter is enabled by default rather than opt-in.
• Connections to the database and to providers are encrypted in transit.
• Security-relevant events are logged so that access and administrative action can be reviewed.
• The codebase has an automated test suite that runs in continuous integration, including tests that assert the tenant boundary and the append-only guarantees, and container images are scanned for known vulnerabilities as part of the build.

It matters as much what is not true. NotiSynk makes none of the following claims, and you should not assume any of them:

• NotiSynk holds no SOC 2 report, no ISO 27001 certification, no PCI DSS certification and no HIPAA attestation.
• NotiSynk has not published an independent penetration test or third-party security audit.
• NotiSynk does not describe its security as bank-grade, military-grade, unbreakable or absolute. No system is.
• NotiSynk does not offer a formal service-level agreement or an uptime guarantee unless one has been agreed separately in writing.

If your own obligations require a certification or an audit report, raise it before relying on the Service for that purpose.

Write to info@notisynk.com with enough detail to reproduce what you found. Please report a weakness rather than exploring it: do not access anyone else's information, do not degrade the Service for others, and give us a reasonable opportunity to fix the problem before disclosing it.

A report made in good faith on those terms is treated as help. Section 8 of the Data Processing Addendum describes what happens if an incident affects a Workspace.