Security Incident Response Policy

This Security Incident Response Policy (the "Policy") describes how MyShipPilot LLC ("MyShipPilot", "we") detects, reports, contains, investigates, remediates and communicates security incidents affecting the MyShipPilot shipping platform. It applies to all personnel, contractors and service accounts that interact with MyShipPilot systems on our behalf.

1. What qualifies as a security incident

• Unauthorized access to, or disclosure of, customer or connected-store personal data.
• Compromise or suspected exposure of a credential, including payment-processor, carrier, platform-integration, database, signing or administrative account credentials.
• Unauthorized use of an administrative account, or elevation of a customer account to an administrative role.
• Confirmed fraudulent label purchasing, refund abuse or carrier-adjustment abuse beyond ordinary risk-engine handling.
• Loss of data integrity or availability, including destructive changes, accidental deletion, database outage or corrupted backups.
• Malicious code or a compromised software dependency reaching production.
• A vulnerability report showing that protected data is reachable without authorization.

Ordinary declined card payments, transient carrier API errors and isolated single-user login failures are not incidents; they are operational events handled through normal support.

2. Roles and responsibilities

• Incident Lead — declares the incident, owns containment, and makes and records the notification decision.
• Technical Responder — performs investigation, credential revocation and rotation, remediation and evidence collection.
• Communications — handles contact with affected customers, merchants, carriers, payment processors and regulators.

MyShipPilot is a small organization. In practice one individual — currently the founder, who also serves as administrator — may perform more than one of these roles, and in a single-operator situation performs all of them. We state the roles separately and explicitly so that no responsibility is skipped simply because the same person carries it. Any responder who suspects an incident is required to declare it rather than investigate silently.

3. Reporting and communication channels

Anyone — customer, merchant, researcher, partner or member of our personnel — may report a suspected security incident or vulnerability through:

• security@myshippilot.com — security incidents and vulnerability reports.
• privacy@myshippilot.com — privacy concerns and personal-data incidents.
• Our contact form for general reports.
• Our machine-readable security.txt disclosure record (RFC 9116).

Reports are reviewed by the Incident Lead. Internally, security-relevant failures and money-path errors also raise durable alerts that are surfaced on an authenticated internal operations view, alongside application error logs, so a report and an automated signal can be correlated. Service availability updates for customers are posted on our status page.

4. Detection

Detection combines inbound reports with automated technical signals produced by the platform: server-side application error logging, durable operational alerts for failures on payment, label and refund paths, an access log recording privileged reads of protected data, an append-only fraud and risk decision trail, processing records for inbound carrier and payment webhook events, and authentication rate-limiting and throttling records. These signals are the timeline sources used during investigation. We do not represent that we operate a 24/7 staffed on-call rotation, a security operations center, a SIEM platform, or network intrusion detection or prevention appliances.

5. Containment

On declaration we record the time, the reporter and the first observation, then act to stop ongoing harm before analysis: freezing an affected account, disabling an affected integration, or taking an affected endpoint out of service. Any credential that may have been exposed is treated as exposed and revoked and rotated, and the dependent flow is verified after rotation. If administrative access is suspect, all sessions for that account are terminated and its password is rotated; administrative sessions additionally expire automatically after a period of inactivity. Evidence — relevant log entries and affected record identifiers — is preserved before any cleanup, and personal data is not copied into the incident record.

6. Investigation and assessment

We determine and write down what happened, the entry point, the time window, which records and accounts were affected, whether personal data was actually accessed or was only reachable, and whether the issue remains live. The access log, privacy-event records, webhook processing records and authentication throttle records provide the timeline.

7. Eradication and remediation

We remove the cause rather than the symptom: correcting the vulnerable code or configuration, closing the authorization gap, revoking compromised credentials and access, and removing any malicious or unauthorized artifact. Fixes are verified by our automated test suite before release, and controls are added or tightened so the same class of issue fails closed in future.

8. Recovery

We deploy the fix and verify core flows — rating, label purchase, refund and tracking — with both automated tests and a live check. Where data was lost, we restore from managed database backups, and never restore over live data without first taking a snapshot. Frozen accounts and disabled integrations are re-enabled only once verified, and we confirm the signal that first detected the incident is clean before closing.

9. Documentation

Every incident receives a dated entry in our internal incident record containing the timestamp, reporter, severity, systems and record counts affected, containment actions, credentials rotated, root cause, remediation, the notification decision and follow-up items. Incident records reference record identifiers and never contain customer personal data.

10. Breach assessment and notification

The Incident Lead assesses whether the incident constitutes a personal-data breach and decides on notification. The decision — including a documented decision not to notify, with reasoning — is recorded in the incident record.

Where notification is required, we notify without undue delay and, where the GDPR applies, within 72 hours of becoming aware of the breach. Depending on the incident, notification recipients may include:

• Merchants and customers whose account or store data was involved, including the connected e-commerce platform where its program obligations apply.
• Affected individuals where the incident is likely to result in a risk to them, such as exposure of identity or address information.
• Regulators where legally required, including under GDPR Article 33 and applicable US state breach-notification laws based on the individual's residence.
• Payment processors, carriers and other service providers where their credentials, systems or data are involved.

Notifications state what happened, what data was involved, what we have done in response, and what the recipient should do.

11. Post-incident review

Within 14 days of closing an incident we conduct a root-cause review and record corrective actions with owners and target dates covering controls, tests and monitoring. Findings are used to update this Policy and our related security documentation so the same class of issue is detected earlier next time.

12. Policy owner and review

This Policy is owned by MyShipPilot LLC. It is effective as of the date shown above and is reviewed at least annually and following material changes to our security posture or systems. Material changes are reflected by updating the "Effective date" shown above. Related documents include our Access Control & Least Privilege Policy and Data Classification & Encryption Policy.

13. Contact

To report a security incident or vulnerability, email security@myshippilot.com. For privacy matters, email privacy@myshippilot.com.

This Policy is a governance statement and does not modify our Terms of Service. In the event of a conflict, the Terms of Service control with respect to your use of the Service.