incident Response & Security Breach Policy
This Incident Response & Security Breach Policy explains how Asiyst approaches the identification, assessment, containment, investigation, remediation, and communication of security incidents that may affect the Asiyst Services or information processed through them. This Policy applies to Asiyst websites, applications, APIs, SDKs, CLI tools, infrastructure, integrations, AI services, and other applicable Services.
1. Purpose
The purpose of this Policy is to establish a structured approach for responding to security incidents and potential data breaches.
Asiyst may use incident-response procedures to:
- Detect security events.
- Assess potential impact.
- Contain threats.
- Investigate incidents.
- Remediate vulnerabilities.
- Restore affected Services.
- Protect customer and user information.
- Meet applicable legal and contractual obligations.
2. Scope
This Policy applies to security incidents involving systems or Services operated or controlled by Asiyst.
It may include incidents involving:
- Unauthorized access.
- Unauthorized disclosure.
- Data loss.
- Data alteration.
- Malware.
- Credential compromise.
- Account compromise.
- Infrastructure compromise.
- Service disruption caused by security events.
- Vulnerabilities.
- Other events that may affect the confidentiality, integrity, or availability of protected information or Services.
3. Definition of Security Incident
A Security Incident means an actual or reasonably suspected event that may compromise the confidentiality, integrity, or availability of Asiyst systems, Services, or information.
Examples may include:
- Unauthorized access to systems.
- Compromised credentials.
- Malicious software.
- Unauthorized modification of data.
- Unauthorized disclosure of information.
- Exploitation of a security vulnerability.
- Denial-of-service activity.
- Other suspicious activity requiring security investigation.
Not every security event constitutes a personal-data breach.
4. Definition of Personal Data Breach
A Personal Data Breach generally means a security incident involving the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or unauthorized access to personal data, where applicable under relevant law.
Whether an incident constitutes a legally reportable breach depends on the facts and applicable jurisdiction.
5. Security Event Detection
Security events may be identified through:
- Automated monitoring.
- Security alerts.
- System logs.
- Access monitoring.
- Vulnerability detection.
- Employee reports.
- Customer reports.
- Third-party notifications.
- Security researchers.
- Service-provider notifications.
Asiyst may use technical and operational controls to identify suspicious activity.
6. Incident Reporting
Potential security incidents should be reported to Asiyst through an appropriate security or support channel.
Reports should provide, where available:
- Description of the suspected issue.
- Affected Service.
- Relevant account or project.
- Approximate time of occurrence.
- Steps required to reproduce the issue.
- Evidence supporting the report.
- Potential impact.
- Reporter contact information.
Do not include unnecessary sensitive personal information in a security report.
7. Security Vulnerability Reports
Security researchers and other parties are encouraged to report suspected vulnerabilities responsibly.
Reports should provide sufficient technical information to allow Asiyst to investigate the issue.
Security testing should be limited to systems and activities that the reporter is authorized to test.
8. Responsible Security Testing
Security researchers should avoid:
- Accessing unrelated user data.
- Modifying or deleting data.
- Disrupting Services.
- Installing persistent access mechanisms.
- Performing destructive testing.
- Conducting denial-of-service attacks.
- Publicly disclosing an unresolved vulnerability without appropriate consideration.
Testing that causes material harm may be treated as unauthorized activity.
9. Initial Assessment
When Asiyst becomes aware of a potential Security Incident, the relevant personnel may conduct an initial assessment to determine:
- What systems may be affected.
- What information may be involved.
- Whether unauthorized access occurred.
- Whether the incident is ongoing.
- Potential severity.
- Potential customer impact.
- Potential legal or contractual obligations.
10. Incident Classification
Incidents may be classified based on factors including:
- Scope.
- Severity.
- Data involved.
- Number of affected users.
- Duration.
- Security impact.
- Service impact.
- Regulatory implications.
Asiyst may use internal severity categories that are not publicly disclosed.
11. Incident Response Team
Depending on the nature of an incident, Asiyst may involve personnel responsible for:
- Security.
- Engineering.
- Infrastructure.
- Privacy.
- Legal.
- Compliance.
- Customer support.
- Communications.
- Executive or management functions.
Third-party specialists may also be engaged where appropriate.
12. Containment
Where necessary, Asiyst may take steps to contain an incident.
Containment measures may include:
- Revoking credentials.
- Disabling accounts.
- Blocking access.
- Isolating systems.
- Restricting network traffic.
- Disabling affected functionality.
- Applying security controls.
- Taking affected systems offline.
Containment measures may temporarily affect Service availability.
13. Credential Compromise
If credentials are suspected of being compromised, Asiyst may:
- Revoke credentials.
- Rotate secrets.
- Require credential resets.
- Restrict account access.
- Invalidate sessions.
- Apply additional authentication requirements.
Customers are responsible for securing credentials under their control.
14. Investigation
Asiyst may investigate relevant technical and operational information to determine the nature and scope of an incident.
Investigation information may include:
- Authentication records.
- Access logs.
- API activity.
- System logs.
- Security alerts.
- Infrastructure events.
- Account activity.
- Configuration information.
Investigation activities will be conducted subject to applicable law and contractual obligations.
15. Evidence Preservation
Where appropriate, Asiyst may preserve relevant records to support:
- Incident investigation.
- Remediation.
- Legal proceedings.
- Regulatory obligations.
- Security analysis.
- Fraud investigations.
Preserved information may be retained for a period different from ordinary operational data retention where legally or operationally necessary.
16. Eradication
Once the source or mechanism of an incident has been identified, Asiyst may take steps to remove or disable the underlying threat.
Actions may include:
- Patching vulnerabilities.
- Removing malicious software.
- Disabling compromised credentials.
- Correcting configurations.
- Blocking malicious activity.
- Rebuilding affected systems.
- Updating security controls.
17. Recovery
After containment and remediation, Asiyst may restore affected Services.
Recovery activities may include:
- Restoring systems.
- Validating system integrity.
- Monitoring affected infrastructure.
- Testing security controls.
- Reviewing access.
- Gradually restoring functionality.
18. Post-Incident Review
Following significant incidents, Asiyst may conduct a post-incident review.
The review may evaluate:
- Root or contributing causes.
- Detection effectiveness.
- Response effectiveness.
- Containment measures.
- Recovery actions.
- Security controls.
- Opportunities for improvement.
The specific contents of internal reviews may remain confidential.
19. Customer Notification
Where a Security Incident materially affects customer information and notification is required by applicable law or contract, Asiyst may notify affected customers through an appropriate communication channel.
Depending on the circumstances, notification may include:
- Nature of the incident.
- Known or reasonably suspected impact.
- Affected Services.
- Relevant categories of information.
- Actions taken by Asiyst.
- Recommended customer actions.
- Available remediation information.
Asiyst may provide additional information as the investigation develops.
20. Timing of Notification
Where notification is legally or contractually required, Asiyst will follow the applicable notification requirements.
Notification timing may depend on:
- Applicable law.
- Contractual obligations.
- Regulatory requirements.
- The status of the investigation.
- Security considerations.
- Availability of sufficiently reliable information.
Asiyst may delay certain information where immediate disclosure could compromise an investigation or security response, where permitted by law.
21. Notification Methods
Notifications may be provided through:
- Email.
- Account notifications.
- Dashboard notifications.
- Website notices.
- Direct communication.
- Other appropriate communication channels.
Customers are responsible for maintaining accurate contact information.
22. Regulatory and Government Notifications
Where required by applicable law, Asiyst may notify relevant:
- Regulatory authorities.
- Government agencies.
- Law-enforcement authorities.
- Other legally authorized entities.
The applicable legal requirements will determine whether, when, and how such notifications are made.
23. Data Protection Authorities
Where applicable privacy or data-protection law requires notification to a supervisory or regulatory authority, Asiyst may make the required notification within the applicable legal timeframe.
The applicable jurisdiction and circumstances determine the specific notification requirements.
24. Customer Responsibilities
Customers are responsible for taking reasonable steps to protect their own environments.
This may include:
- Protecting credentials.
- Restricting user access.
- Maintaining secure configurations.
- Monitoring API usage.
- Rotating compromised credentials.
- Maintaining appropriate backups.
- Securing connected systems.
- Investigating suspicious activity.
25. Customer Security Incidents
If an incident originates in a customer's systems or environment, the customer remains responsible for responding to that incident.
Examples may include:
- Compromised customer credentials.
- Compromised customer application.
- Insecure customer configuration.
- Unauthorized access through a customer-controlled integration.
- Security vulnerabilities in a customer application.
Asiyst may provide reasonable assistance where required by applicable agreement or law.
26. Third-Party Security Incidents
Asiyst may depend on third-party infrastructure and service providers.
If a security incident occurs within a third-party service that affects Asiyst, Asiyst may coordinate with the relevant provider and assess potential impact on Asiyst customers.
Third-party providers may have their own incident-response and notification procedures.
27. AI Provider Incidents
Where Asiyst uses third-party AI providers, an incident involving a provider may affect information processed through that provider.
Asiyst may assess:
- What information was involved.
- Whether Asiyst customer information was affected.
- The provider's investigation.
- Applicable contractual requirements.
- Applicable legal obligations.
Provider-specific incidents may also be subject to the provider's own policies.
28. Payment Provider Incidents
Payment processing may be performed by third-party payment providers.
Payment-related security incidents may therefore involve the relevant payment provider's systems.
Where Asiyst receives information about an incident affecting customer payment information, Asiyst may coordinate with the relevant provider and take applicable response measures.
29. Subprocessors
Asiyst may use subprocessors to provide infrastructure, storage, communications, AI processing, analytics, or other functionality.
Security incidents involving subprocessors may be handled according to applicable contractual and data-processing arrangements.
Relevant subprocessors may be listed through the Asiyst Subprocessors information.
30. Data Minimization During Response
Asiyst may seek to limit access to information during incident investigations to what is reasonably necessary for the investigation and response.
Access may be restricted based on:
- Role.
- Incident scope.
- Data sensitivity.
- Business need.
- Legal requirements.
31. Confidentiality
Incident investigations may involve confidential information.
Asiyst may restrict access to investigation information to personnel and advisers with a legitimate need to know.
Certain investigation records may not be publicly disclosed where disclosure could:
- Increase security risk.
- Reveal defensive controls.
- Expose confidential information.
- Interfere with legal proceedings.
- Affect an ongoing investigation.
32. Security Logs
Security logs may be used to:
- Detect suspicious activity.
- Investigate incidents.
- Establish timelines.
- Identify affected systems.
- Support remediation.
- Meet legal or contractual requirements.
Retention of security logs is governed by applicable security and data-retention practices.
33. Backups
Backups may be used as part of recovery from certain security incidents.
Backup restoration may be subject to:
- Integrity verification.
- Security review.
- Recovery procedures.
- Applicable retention requirements.
Backups are not necessarily immediately available for customer access.
34. Business Continuity
Security incidents may affect Service availability.
Asiyst may use operational continuity and recovery procedures intended to restore affected Services while maintaining appropriate security controls.
Specific availability commitments, where applicable, are governed by the relevant Service Level Agreement.
35. Vulnerability Remediation
When a vulnerability is identified, Asiyst may evaluate:
- Severity.
- Exploitability.
- Affected systems.
- Potential impact.
- Available mitigation.
- Required remediation.
Remediation may include:
- Software updates.
- Configuration changes.
- Access restrictions.
- Infrastructure changes.
- Additional monitoring.
- Other security measures.
36. Security Updates
Asiyst may update its security controls following incidents or newly identified risks.
Updates may include:
- Authentication controls.
- Access policies.
- Monitoring.
- Network controls.
- Application security.
- Infrastructure security.
- Credential management.
- Data protection mechanisms.
37. Customer Cooperation
Where a security incident involves customer-controlled systems, Asiyst may request information or assistance reasonably necessary to investigate or mitigate the incident.
Customers should cooperate with reasonable security requests where appropriate.
38. Emergency Security Measures
Asiyst may take immediate protective action where necessary to protect:
- Customer information.
- User accounts.
- Infrastructure.
- Other customers.
- The Services.
- Third-party systems.
Emergency actions may include temporary suspension, access restrictions, credential revocation, or Service disruption.
39. Abuse and Fraud
Security investigations may overlap with suspected:
- Fraud.
- Account abuse.
- Credential theft.
- Payment abuse.
- Automated abuse.
- Unauthorized access.
- Other prohibited activity.
Asiyst may use security information to investigate and respond to such activity.
40. Law Enforcement
Asiyst may cooperate with law-enforcement authorities where required by applicable law or valid legal process.
Asiyst may preserve or disclose information where legally required.
41. Customer Notification Exceptions
Notification may be limited, delayed, or provided through an alternative mechanism where permitted by applicable law, including circumstances where notification could:
- Compromise an investigation.
- Increase security risk.
- Expose another person's confidential information.
- Conflict with a legal restriction.
- Be prohibited by a competent authority.
42. No Guarantee of Incident Prevention
Asiyst maintains security measures intended to reduce security risks, but no system can be guaranteed to be completely secure.
Asiyst does not represent that Security Incidents can never occur.
43. Customer Security Responsibilities
Customers should maintain appropriate security practices for systems connected to Asiyst.
Recommended measures may include:
- Strong authentication.
- Least-privilege access.
- Secure credential storage.
- Regular credential rotation.
- Security monitoring.
- Dependency updates.
- Secure application configuration.
- Employee access controls.
- Appropriate backups.
44. Security Contact
Security concerns should be reported through the appropriate Asiyst security or support channel.
When reporting a potential vulnerability, provide enough information for Asiyst to investigate without unnecessarily exposing confidential or personal information.
45. Relationship With Other Policies
This Policy should be read together with applicable Asiyst policies and agreements, including:
- Security Policy.
- Security & Trust Center.
- Privacy Policy.
- Data Processing Agreement.
- Data Retention Policy.
- Data Deletion Policy.
- Subprocessors information.
- Terms of Service.
- API Terms.
- Developer Terms.
- Service Level Agreement.
Where a separate written agreement imposes specific incident-response obligations, that agreement controls to the extent of any conflict.
46. Changes to This Policy
Asiyst may update this Incident Response & Security Breach Policy to reflect changes in:
- Security practices.
- Infrastructure.
- Services.
- Legal requirements.
- Incident-response procedures.
- Regulatory requirements.
The current version of this Policy will be made available through the Asiyst website.
47. Contact
For questions concerning security incidents, suspected breaches, or security vulnerabilities, contact:
Asiyst Website: https://asiyst.com Email: support@asiyst.com