Totesoft Security Policy

This Security Policy exists so that Customers, platform providers, and security reviewers can understand which security controls Totesoft owns, which controls are provided by the platform on which an App runs, and what Totesoft commits to do when a vulnerability or Security Incident arises.

This Security Policy applies to all Totesoft Personnel and to every App. Where an App runs entirely inside a platform provider's infrastructure (for example, an Atlassian Forge app with no external egress), the platform provider supplies most infrastructure controls and Totesoft's obligations concentrate on application code, permissions, access to developer tooling, and operational conduct. Section 3 allocates those responsibilities.

In this Security Policy, the following terms have the meanings given below. Each defined term has the same meaning wherever it appears.

1. "App" means a software application that Totesoft develops and publishes on a Marketplace, including each version, environment, and edition of that application.
2. "Customer" means the organization that installs an App on its own tenant, site, or domain and, for purposes of applicable data protection law, acts as the data controller of Customer Data.
3. "Customer Data" means data that an App accesses, processes, stores, or logs on behalf of a Customer, including End-User Data as defined by the applicable Marketplace Partner Agreement. Customer Data excludes Totesoft's own business records and de-identified operational metrics that contain no Customer content.
4. "Marketplace" means the Atlassian Marketplace, the Google Workspace Marketplace, or any comparable distribution channel operated by a Platform Provider through which Totesoft publishes an App.
5. "Personnel" means Totesoft's members, employees, and any contractor Totesoft engages who is granted access to App source code, Platform Provider developer tooling, or Customer Data.
6. "Platform Provider" means Atlassian Pty Ltd and its affiliates (for Atlassian Forge and Atlassian Cloud products) or Google LLC and its affiliates (for Google Workspace and Google Cloud), as applicable to a given App.
7. "Production Environment" means the deployed instance of an App that Customers install from a Marketplace, as distinct from development and staging environments.
8. "Security Incident" means any confirmed unauthorized access to, or unauthorized use, disclosure, alteration, loss, or destruction of, Customer Data or App source code, credentials, or deployment tooling. A Security Incident does not include an unsuccessful attempt, or a Vulnerability for which there is no evidence of exploitation.
9. "Vulnerability" means a weakness in an App, or in Totesoft's development or operational practices, that could be exploited to compromise the confidentiality, integrity, or availability of Customer Data or of a Customer's environment.

Totesoft builds Apps to run inside the Platform Provider's infrastructure wherever the platform permits, so that infrastructure security is provided by the Platform Provider under its own published programs and certifications. The table below states, for each control area, which party is responsible for the Apps covered by this Security Policy. For Atlassian Forge apps, the allocation follows Atlassian's Forge shared responsibility model. Any App that departs from this model (for example, by egressing Customer Data to a Totesoft-operated service) will say so in its Annex A profile, and Totesoft will assume the additional responsibilities identified there before the App is released.

Control area	Platform Provider	Totesoft
Physical security, data-center operations, hosting hardware	Provided by Platform Provider	Not applicable; Totesoft operates no data centers or servers for the Apps
Network security, DDoS protection, TLS termination, HSTS	Provided by Platform Provider for all App traffic that stays within the platform	Not applicable for non-egressing Apps; Totesoft-owned for any endpoint Totesoft operates
Encryption in transit and at rest for Customer Data held in platform storage and logs	Provided by Platform Provider (Forge hosted storage, Forge logs, Google Cloud services)	Totesoft confirms in each App's profile that no Customer Data is stored outside the platform; if it ever is, Totesoft owns full-disk encryption at rest
Tenant isolation and runtime sandboxing	Provided by Platform Provider	Totesoft owns correct use of platform isolation (per-installation storage keys, no cross-tenant lookups)
Platform authentication and authorization (OAuth, app identity, installation tokens)	Provided by Platform Provider	Totesoft owns the scopes an App requests and their justification
Application code, business logic, input validation, output handling	Not applicable	Totesoft-owned (Section 6)
Permissions and scopes requested by the App	Enforced by Platform Provider	Selected, minimized, and justified by Totesoft (Section 6.4)
Third-party dependencies bundled into the App	Not applicable	Totesoft-owned (Section 6.5)
App configuration secrets and environment variables	Secret storage mechanism provided by Platform Provider	Totesoft owns what is stored, who can set it, and rotation
Access to developer console, CLI, deployment, and log viewing	Identity and 2SV mechanisms provided by Platform Provider	Totesoft owns who holds access and how it is protected and revoked (Section 5)
Diagnostic logging content and verbose-mode controls	Log infrastructure and retention provided by Platform Provider	Totesoft owns log content, data minimization, and any verbose mode (Section 8)
Vulnerability scanning of published App artifacts	Performed by Platform Provider (for example, Atlassian Ecoscanner and AMS)	Totesoft owns triage and remediation within published timeframes (Section 9)
Incident detection within platform infrastructure	Provided by Platform Provider	Totesoft owns detection within App logs, response, and Customer notification (Section 10)
Customer-side administration (who installs the App, which projects or fields it is configured on, user permissions)	Tooling provided by Platform Provider	Not applicable; the Customer is responsible

1. Accountability. Totesoft designates one of its members as security owner. The security owner is accountable for this Security Policy, for the security contact mailbox, and for coordination with Platform Providers on Vulnerabilities and Security Incidents.
2. Confidentiality. Every member of Personnel is bound by written confidentiality obligations covering App source code, credentials, and Customer Data before receiving access to any of them.
3. Awareness. Personnel with access to Platform Provider tooling review this Security Policy and the Platform Provider's current security requirements for Marketplace apps at onboarding and at least annually thereafter.
4. Separation. Totesoft keeps App development and deployment credentials separate from the credentials Totesoft uses for its other lines of business, including its IT services and revenue-cycle-management subcontracting work. Customer Data from one line of business is not used in another.
5. Devices. Personnel access App source code and Platform Provider tooling only from devices that have full-disk encryption enabled, an up-to-date operating system with automatic security updates, a screen lock, and endpoint protection.

1. Named accounts. Each member of Personnel uses an individual, named account for the Platform Provider developer console, CLI, source-code repository, and Marketplace partner account. Totesoft does not use shared accounts for these systems.
2. Multi-factor authentication. Two-step verification is enabled on every Atlassian account, Google account, and source-code repository account that holds access to an App. Totesoft complies with Atlassian's two-step verification requirement for Marketplace partners.
3. Least privilege. Personnel receive the minimum role needed for their work. Production deployment rights are limited to the security owner and to Personnel the security owner has designated in writing.
4. Credential handling. Personnel store passwords, API tokens, and CLI credentials in a password manager. Credentials are never committed to source control, embedded in App code, or transmitted in plain text. Any credential that is exposed is rotated on the day the exposure is discovered.
5. Access reviews. The security owner reviews the list of Personnel with access to each App's developer console, repository, and Marketplace partner account at least every six months and whenever Personnel change role.
6. Revocation. When a member of Personnel leaves Totesoft or no longer requires access, Totesoft revokes that person's access to all App-related systems within one business day and rotates any shared secret that person could have obtained.

1. Source control. All App source code, manifests, and infrastructure configuration are kept in a private version-controlled repository. Every change to the Production Environment is traceable to a commit and to the person who deployed it.
2. Review before release. No change reaches the Production Environment without review against a documented pre-release checklist covering the items in this Section 6. Where more than one engineer is assigned to an App, a second engineer reviews each production change. Where a single engineer maintains an App, the checklist review is recorded and automated checks (Section 6.6) must pass before deployment.
3. Environments. Totesoft maintains separate development, staging, and production environments for each App. Development and staging environments use synthetic or Totesoft-owned test data. Customer Data is not copied into non-production environments.
4. Least-privilege permissions. Each App requests only the platform scopes required for its documented functionality. Before release, and before any scope change, the security owner records a written justification for each scope, which Totesoft also publishes in the App's Marketplace listing where the Marketplace provides a field for it. Scopes that grant read or write access beyond the App's documented purpose are not requested.
5. Dependency management. Third-party packages are pinned through a lockfile, sourced only from official registries, and checked for known vulnerabilities before each release. Totesoft remediates dependency vulnerabilities within the timeframes in Section 9.4.
6. Automated testing. Each App has an automated test suite that runs before deployment. Where an App's privacy policy makes a data-minimization statement that is enforced in code (for example, that a stored diagnostic record never contains field values or free-form Customer text), that statement is covered by a test that fails if the behavior changes.
7. Secure coding. Totesoft validates and constrains all input received from the platform, Customer configuration, and API responses; uses the Platform Provider's supplied APIs and libraries rather than hand-built alternatives for authentication and requests; and avoids executing dynamically constructed code.
8. Deployment. Production deployments are made through the Platform Provider's official tooling by authorized Personnel from a 2SV-protected account. Totesoft does not publish App artifacts from an automated pipeline unless the pipeline's credentials are held to the standard in Section 5.
9. Change disclosure. If a release changes what Customer Data an App accesses, stores, or logs, or adds an external service or subprocessor, Totesoft updates the App's privacy policy and Marketplace privacy and security disclosures before releasing the change.

1. Minimization. Totesoft designs each App to access, hold in memory, store, and log the least Customer Data needed for its documented function. Each App's privacy policy states specifically what is accessed, stored, and logged.
2. No egress by default. Totesoft's Apps do not transmit Customer Data to any Totesoft-operated server or to any third party unless the App's Annex A profile expressly states otherwise. Totesoft does not use Customer Data for analytics, advertising, or model training.
3. Encryption. Customer Data held in Platform Provider storage and logs is encrypted in transit and at rest by the Platform Provider. If Totesoft ever stores Customer Data outside a Platform Provider's infrastructure, Totesoft will apply full-disk encryption at rest and TLS 1.2 or higher in transit, and will disclose that storage in the App's profile before release.
4. Secrets and credentials. Totesoft's Apps do not request, collect, or store user passwords, personal access tokens, or other shared secrets belonging to Customers or their users.
5. Retention and deletion. Retention periods and deletion mechanisms for each App are stated in that App's privacy policy. Totesoft does not promise a deletion method the App or platform does not technically provide.
6. Data subject and Customer requests. Totesoft acknowledges requests concerning Customer Data within three business days of receipt at support@totesoft.com and handles them according to the applicable App privacy policy.

1. Log content. During normal operation an App writes structured diagnostic entries that identify the operation, outcome, and technical context of a run, and that exclude field values, message bodies, and other Customer content wherever the App's design permits. Each App's privacy policy states exactly what its logs contain.
2. Log access. Only Personnel with a named, 2SV-protected developer account can view App logs, and only through the Platform Provider's console. Log retention is governed by the Platform Provider.
3. Verbose diagnostic modes. Where an App offers a verbose logging mode that would cause Customer content to appear in logs, that mode is disabled by default, can be enabled only by the security owner or a designee, is enabled only to investigate a specific fault reported by a Customer, and is disabled when the investigation concludes. Totesoft records each activation, its purpose, and its duration.
4. Support access. Totesoft accesses a Customer's installation-scoped diagnostics only in connection with a support request from that Customer's administrator or a Security Incident affecting that Customer. Totesoft has no mechanism to read Customer Data back from a Customer's site except through the Platform Provider's own logs and tooling.
5. Monitoring. Totesoft reviews App error rates and failure logs on a regular cadence and after each release, and treats an unexplained change in error patterns as a trigger for investigation under Section 10.

1. Reporting. Anyone may report a suspected Vulnerability in an App to security@totesoft.com. Reporters should not include live Customer Data or production credentials in an initial report. Totesoft will not pursue legal action against a reporter who acts in good faith, tests only against their own or Totesoft's environments, and gives Totesoft a reasonable opportunity to remediate before public disclosure.
2. Acknowledgment. Totesoft acknowledges each report within three business days and provides the reporter with a triage outcome within ten business days.
3. Platform channels. Totesoft maintains a current security contact in its Marketplace partner account, monitors tickets assigned to it in the Atlassian Marketplace Security (AMS) project, and responds to Platform Provider scanner findings and security requirements notices within the platform's expected triage period.
4. Remediation timeframes. Totesoft rates each confirmed Vulnerability using CVSS v3.1 or later and remediates it within the following timeframes, measured from the date the Vulnerability is reported or triaged, whichever the Platform Provider's policy specifies. These timeframes match Atlassian's Security Bug Fix Policy for Marketplace cloud apps, and Totesoft will adopt any shorter timeframe a Platform Provider later publishes.

   Severity	CVSS score	Fixed within
   Critical	9.0 or higher	10 days
   High	7.0 to 8.9	4 weeks
   Medium	4.0 to 6.9	12 weeks
   Low	below 4.0	25 weeks

5. Extensions. Totesoft requests an extension to a remediation date only on the grounds the Platform Provider accepts (for example, a fix that depends on a platform change or that would break Customer installations) and only through the Platform Provider's process.
6. Disclosure. After a Vulnerability is remediated, Totesoft publishes a release note that identifies the affected versions and the fix at a level of detail that does not enable exploitation of unpatched installations. Where the Platform Provider auto-updates the App, Totesoft states that in the note.
7. Security testing. Totesoft performs its own security review of each App before initial release and after any change to scopes, storage, logging, or external connectivity. Totesoft will state in each App's Annex A profile whether the App is enrolled in a Platform Provider vulnerability disclosure or bug bounty program and whether a third-party penetration test has been performed.

1. Plan. Totesoft maintains a written incident response procedure covering detection, classification, containment, eradication, recovery, notification, and post-incident review. The security owner leads the response.
2. Containment. On confirming a Security Incident, Totesoft immediately takes the containment steps available to it, which may include rotating credentials, disabling a verbose logging mode, deploying a patched version, or requesting that the Platform Provider pause the App.
3. Platform Provider notification. Totesoft notifies the Platform Provider of a Security Incident affecting an App through the Platform Provider's designated channel and within the timeframe the Platform Provider's partner incident program requires, and cooperates with the Platform Provider's investigation.
4. Customer notification. Totesoft notifies each affected Customer's administrator contact without undue delay and no later than 72 hours after confirming that the Customer's data was affected. The notification describes what happened, what data was involved, what Totesoft has done, and what the Customer can do, and identifies a contact for follow-up. Totesoft provides updates as material facts change and a closing summary when the incident is resolved.
5. Legal obligations. Totesoft gives any notice required by applicable data protection or breach-notification law within the time that law requires, and in any event the timing in Section 10.4 does not extend a shorter statutory deadline.
6. Post-incident review. Within 30 days after resolution, Totesoft completes a written review identifying root cause, the controls that failed or were absent, and the corrective actions adopted, and updates this Security Policy where the review calls for it.
7. Records. Totesoft retains incident records, including timeline, decisions, and notifications sent, for at least three years.

1. Platform availability. The availability of each App in the Production Environment depends on the Platform Provider's infrastructure, which the Platform Provider operates under its own service commitments and status reporting. Totesoft does not operate infrastructure that an App depends on at runtime unless stated in Annex A.
2. Source and configuration recovery. App source code, manifests, and deployment configuration are held in a hosted version-control service with off-site redundancy. Totesoft can rebuild and redeploy any App from the repository using Platform Provider tooling.
3. Key-person continuity. Because Totesoft is a small organization, Totesoft designates a secondary member of Personnel who holds recovery access to the source repository, the Marketplace partner account, and the Platform Provider developer console, so that a security fix can be deployed if the primary maintainer is unavailable.
4. Customer Data recovery. Customer Data that an App keeps in Platform Provider storage is recoverable only to the extent the Platform Provider's data lifecycle permits, as described in each App's privacy policy. Totesoft does not maintain independent backups of Customer Data.

1. Current subprocessors. For each App, the only third party that processes Customer Data is the Platform Provider that hosts the App, under the Customer's own agreement with that Platform Provider. Totesoft engages no other subprocessor for Customer Data unless the App's Annex A profile and privacy policy list one.
2. Adding a subprocessor. Before engaging a new subprocessor for Customer Data, Totesoft assesses the subprocessor's security practices, binds it to written data-protection terms no less protective than this Security Policy, updates the App's privacy policy and Marketplace disclosures, and releases the change only after those updates are published.
3. Tooling vendors. Vendors that Totesoft uses for development, source control, and communications do not receive Customer Data. Totesoft applies the access controls in Section 5 to those accounts.

1. Certifications. Totesoft does not currently hold SOC 2, ISO 27001, or similar third-party certifications for its own operations. Infrastructure controls for the Apps are covered by the Platform Provider's certifications, which the Platform Provider publishes on its trust site. Totesoft will not represent that a Platform Provider's certification extends to Totesoft's own organizational controls.
2. Marketplace requirements. Totesoft complies with the Atlassian Marketplace Partner Agreement, Atlassian's security requirements for cloud apps, and the corresponding Google Workspace Marketplace program policies, as each is in force from time to time, and completes the identity and business verification each Marketplace requires.
3. Disclosures. Totesoft completes and maintains the privacy and security disclosures each Marketplace provides for its Apps, including the Atlassian Marketplace Privacy and Security tab, and updates them before releasing any change that would make them inaccurate.
4. Customer questionnaires. Totesoft responds to a Customer's security questionnaire or assessment request within ten business days of receipt at security@totesoft.com. Totesoft will provide a completed CAIQ Lite or equivalent self-assessment for an App on request.
5. Accuracy. Every statement in this Security Policy describes a control Totesoft actually operates. Where a control is aspirational or not yet implemented, Totesoft says so rather than stating it as present.

1. The security owner reviews this Security Policy at least annually, after any Security Incident, and whenever a Platform Provider materially changes its security requirements for Marketplace apps.
2. Totesoft records each revision by updating the version number and effective date above. Material changes are noted in the release notes of any affected App.
3. If this Security Policy conflicts with an App's privacy policy on a question of what data the App handles, the App's privacy policy controls. If they conflict on a question of Totesoft's security practices, this Security Policy controls.

Security reports and assessment requests: security@totesoft.com
Support and data requests: support@totesoft.com
General: info@totesoft.com