TRUST AND SECURITY

How Qity handles security incidents

This page reproduces the substance of Qity's controlled procedure DOC-836, so a security reviewer can assess the process without waiting for a document request.

Trust overview Security controls Incident management Vulnerability management Data processing agreement Sub-processors

REPORT AN INCIDENT

Customers, researchers, and suppliers should write to security@qity.be. Include what you observed, when, the affected app or system, and how to reach you. If personal data may be involved, copy dpo@qity.be.

ATLASSIAN P1

Within 24 hours

CUSTOMER ADVISORY

Within 72 hours where possible

ATLASSIAN UPDATES

Every 6 hours, Critical and High

DOC-836SOP, Security Incident ManagementRELEASED

VERSION: 1
CHANGE RECORD: DC-1005
EFFECTIVE: 7 July 2026
NEXT REVIEW: 7 July 2027
OWNER: Miguel Azevedo

DOCUMENT APPROVAL

Miguel AzevedoSakshi KaleDimitri Crelot

QA APPROVALJean-Francois LadryAPPROVED

1. Purpose

This procedure defines the process for identifying, reporting, triaging, investigating, containing, communicating, remediating, reviewing, and closing security incidents affecting Qity products, services, systems, suppliers, data, customers, and Atlassian Marketplace apps.

It ensures that security incidents are managed in a controlled manner under Qity's QMS and PIMS, including incident records, customer communication, personal data breach assessment, Atlassian notification, security advisory preparation, corrective action, and management review.

2. Scope

The procedure applies to all Qity personnel involved in product development, operations, support, security, privacy, customer communication, supplier management, software maintenance, and Atlassian Marketplace app management. It applies to actual or suspected security incidents affecting four areas.

Area	Examples
Qity products and services	Qity QMS, Qity apps, Atlassian Marketplace apps, integrations, support services, implementation environments, and customer-facing configurations.
Qity systems	Atlassian Cloud, repositories, CI/CD, cloud infrastructure, identity and access management, logging, monitoring, support systems, and documentation environments.
Customer and end user data	Customer data, end user data, personal data, confidential information, credentials, logs, support attachments, and system-generated records.
Suppliers and sub-processors	Hosting providers, development tools, monitoring tools, Atlassian, security tooling providers, support platforms, and other providers that may affect security or privacy.
Security communications	Customer advisories, Atlassian incident notifications, controller notifications, internal updates, supplier communications, supervisory authority communications, and post-incident summaries.

For Atlassian Marketplace apps, the procedure applies when there is actual or suspected unauthorised access, acquisition, use, disclosure, modification, or destruction of end user data, a security compromise of the Marketplace app, or an issue that materially degrades Atlassian systems or networks. Atlassian identifies those situations as security incidents for Marketplace apps.

3. Background

Security incident management supports Qity's Quality Manual requirements for controlled operations, product and service conformity, customer communication, supplier control, risk management, software maintenance, record integrity, and continual improvement. It also supports the PIMS by ensuring that incidents involving personal data are assessed for privacy impact, controller or processor role, breach notification, data subject communication, and records of accountability.

Quality area	Relationship to this procedure
QMS governance and process control	Defines the controlled process for security incident handling.
Customer communication	Defines when and how customers are informed of security incidents and required actions.
Product development and maintenance	Defines how security incidents trigger investigation, remediation, release assessment, and change control.
Supplier management	Defines how supplier-originated incidents are escalated and assessed.
Risk management	Defines how incident-related risks and controls are reviewed.
Data protection and PIMS governance	Defines how personal data breach assessment and privacy notification decisions are handled.
Corrective and preventive action	Defines when incident root cause or recurrence risk requires CAPA.
Document and record control	Defines the required controlled records for incident handling and closure.

4. Definitions

Term	Definition
Security Incident	An actual or suspected event that compromises, may compromise, or materially affects the confidentiality, integrity, availability, resilience, security, or controlled operation of Qity systems, products, services, source code, credentials, infrastructure, customer environments, or data.
Atlassian Marketplace Security Incident	A Security Incident involving a Qity Marketplace app, including actual or suspected unauthorised access, acquisition, use, disclosure, modification, or destruction of end user data, a security compromise of the app, or an issue that materially degrades Atlassian systems or networks.
End User Data	Data, content, information, personal data, files, images, code, or other material made available to Qity through an Atlassian Marketplace app by or on behalf of an end user.
Personal Data Breach	A breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored, or otherwise processed.
Security Incident Record	The controlled QMS record used to document triage, classification, investigation, containment, communication, remediation, PIMS assessment, QMS assessment, post-incident review, and closure.
Customer Advisory	A controlled external communication issued to affected or potentially affected customers about a Security Incident, including impact, remediation, and required customer action.
ECOHELP	Atlassian’s ecosystem support channel used for Marketplace partner support and security incident handling.
AMS	Atlassian Marketplace Security, the Atlassian Jira project used for Marketplace app security issues and vulnerability tracking.
P1 Incident Ticket	A priority 1 incident ticket raised to Atlassian for a security incident impacting a Marketplace app.
Post-incident Review	A documented review performed after containment and remediation to confirm resolution, identify lessons learned, assess corrective actions, and determine whether QMS or PIMS updates are required.

5. Responsibilities and training

Roles are assigned at triage, not improvised during the incident. Each carries a training level recorded in the QMS: training with expert for the four response roles, self-training for the rest.

Role	Responsibilities	Training
Senior Management	Approves major incident decisions, customer communication, public communication, regulatory escalation, CAPA decisions, and closure for Critical and High incidents. Ensures resources are available for investigation, containment, remediation, and customer support.	Self-training
Incident Commander	Coordinates the response, creates and maintains the Security Incident Record, assigns actions, tracks timelines, coordinates internal and external communication, and prepares closure.	With expert
Security Lead	Performs technical triage, investigation, containment, remediation planning, evidence preservation, verification, and technical closure recommendation.	With expert
Privacy Lead	Performs PIMS assessment, personal data breach assessment, controller or processor role assessment, DPIA impact review, and privacy notification decisions.	With expert
Atlassian Security Contact	Communication with Atlassian for Marketplace security incidents, AMS tickets, ECOHELP tickets, P1 incident tickets, and related Atlassian incident support.	With expert
Product Owner	Assesses product, customer, feature, release, and configuration impact, and required customer action.	Self-training
Development Lead	Implements and verifies technical remediation, hotfixes, rollback, patching, dependency updates, code review, and release evidence.	With expert
Support Lead	Coordinates customer support responses, support tickets, customer questions, and advisory distribution under approved communication.	Self-training
Supplier Owner	Escalates supplier-originated incidents, obtains supplier evidence, assesses supplier impact, and coordinates supplier corrective action.	Self-training
QA	Confirms QMS impact assessment, record completeness, change control linkage, CAPA linkage, and closure readiness.	Self-training
Personnel	Report actual or suspected security incidents immediately and preserve relevant evidence.	Self-training

6. When the procedure starts and stops

The process starts when an actual or suspected security event is identified or reported. It ends when the incident has been contained, investigated, remediated or transferred to controlled follow-up records, communicated where required, reviewed, and approved for closure.

Entry criteria

Trigger	Example
A security event is detected internally.	Monitoring alert, suspicious login, unexpected permission change, deployment anomaly, logging alert, or credential exposure.
A customer reports a possible security issue.	Unexpected access, data visibility issue, suspicious system behaviour, or potential compromise.
A customer or supplier reports an incident.	Notification through security@qity.be of a perceived incident, cloud provider incident, sub-processor breach, tool compromise, or dependency compromise.
Atlassian reports or escalates an issue.	AMS ticket, ECOHELP ticket, P1 incident communication, Marketplace security escalation, or Atlassian Security request.
A vulnerability shows evidence of exploitation.	Bug bounty report, penetration test finding, active exploit, or credible threat intelligence.
Personal data may have been affected.	Unauthorised access, loss, alteration, disclosure, or unavailability of personal data.
A Marketplace app may be compromised.	Unauthorised code change, stolen token, suspicious Forge app behaviour, supply-chain compromise, or active exploitation.

Exit criteria

Criterion	Required state
Classification is complete.	Final severity, scope, affected systems, affected data, and rationale are documented.
Containment is complete.	Further exposure, compromise, or customer impact has been stopped or controlled.
Investigation is complete.	Root cause, duration, affected customers, systems, and data are documented, or remaining limitations are explicitly stated.
PIMS assessment is complete.	Personal data breach assessment is completed or non-applicability is justified.
Atlassian obligations are complete.	Required P1, ECOHELP, AMS, updates, remediation plan, and post-incident review submissions are completed where applicable.
Customer communication is complete.	The advisory decision is documented and communication has been issued where required.
Remediation is verified.	Technical and organisational remediation is complete or transferred to controlled follow-up records.
QMS impact is addressed.	Related change, CAPA, supplier, risk, training, support, and release records are linked where required.
Closure is approved.	Required reviewers approve incident closure.

7. The twelve activities

Each activity below carries its purpose, inputs, outputs, related controlled documents, and the numbered role actions as they appear in the procedure.

8.1

Report and record the event

Security events are reported and captured in a Security Incident Record.

PersonnelReport actual or suspected security events immediately to the Security Lead, Privacy Lead, Incident Commander, or Senior Management. security@qity.be is communicated as the primary contact point for security questions and concerns relating to the Atlassian Marketplace apps.
Support LeadEscalate customer-reported security issues to the Incident Commander and link the support ticket to the Security Incident Record.
Incident CommanderCreate the Security Incident Record and record the source, date, time, reporter, initial description, and immediate concern.
Incident CommanderAssign the Security Lead and determine whether the Privacy Lead, Atlassian Security Contact, Product Owner, or Supplier Owner is required.
QAConfirm that the Security Incident Record is controlled and traceable where the event may affect QMS records or product conformity.

PURPOSE: To ensure that potential incidents are not lost, informally handled, or resolved without traceability.
INPUTS: Report, alert, customer ticket, supplier notice, Atlassian ticket, monitoring alert, vulnerability report, or internal observation.
OUTPUT: Security Incident Record created and initial owner assigned.
RELATED DOCUMENTS: Document and Record Control SOP, Customer Support SOP, Vulnerability Management SOP, Data Breach Management SOP.

8.2

Triage and classify the incident

The event is assessed to determine whether it is a Security Incident and to assign severity, scope, and required response.

Incident CommanderClassify the event as confirmed incident, suspected incident, vulnerability, support issue, supplier issue, privacy event, false positive, or other event.
Security LeadAssess the likely technical scope, affected systems, exploitability, containment need, and evidence required.
Privacy LeadAssess whether personal data may be affected and whether the Data Breach Management SOP is triggered.
Atlassian Security ContactAssess whether the event involves a Marketplace app, end user data, Atlassian systems, Atlassian networks, AMS, ECOHELP, shared secrets, or Atlassian customer trust.
Incident CommanderAssign severity as Critical, High, Medium, or Low using the severity matrix.
Senior ManagementConfirm escalation for Critical and High incidents.

PURPOSE: To ensure proportionate response, timely escalation, and correct routing to QMS, PIMS, supplier, customer, or Atlassian processes.
INPUTS: Security Incident Record, initial report, affected systems, available logs, customer information, supplier notification, Atlassian ticket, or vulnerability report.
OUTPUT: Initial classification, severity, assigned roles, and initial action plan.
RELATED DOCUMENTS: Risk Management process, Data Breach Management SOP, Vulnerability Management SOP, Supplier Management SOP.

8.3

Contain the incident

Immediate action is taken to stop or reduce exposure, compromise, data loss, service impact, or customer impact.

Security LeadDefine immediate containment actions based on the affected system, data, and severity.
Development LeadImplement technical containment, including patch, rollback, feature disablement, token rotation, secret rotation, or configuration change.
Atlassian Security ContactCoordinate with Atlassian where containment affects a Marketplace app, shared secret, Atlassian customer, Atlassian system, or app listing.
Supplier OwnerEscalate to suppliers where supplier action is required to contain the incident.
Incident CommanderRecord each containment action, owner, date, time, rationale, and verification evidence.
Senior ManagementApprove high-impact containment actions, including customer-facing service restriction, app suspension, app delisting, or public communication.

PURPOSE: To protect customers, users, data subjects, Qity systems, Atlassian systems, and evidence while the investigation continues.
INPUTS: Initial triage, affected assets, affected customers, logs, current system state, access information, and severity classification.
OUTPUT: Containment actions implemented and recorded.
RELATED DOCUMENTS: Software Change Control SOP, Access Control process, Supplier Management SOP, Data Breach Management SOP.

Atlassian expects partners to contain Marketplace app incidents as rapidly as possible to prevent further customer impact, including potential loss of end user data, and notes that containment may require temporary restriction of access or delisting while remediation is implemented.

8.4

Investigate the incident

The technical, operational, customer, privacy, and supplier aspects of the incident are investigated.

Security LeadInvestigate root cause, exploitability, affected systems, affected data, evidence of unauthorised access, and duration.
Development LeadReview code, configuration, deployment, dependencies, access paths, and release history.
Product OwnerAssess product, feature, customer, tenant, and service impact.
Privacy LeadAssess personal data categories, affected data subjects, processing role, breach risk, and notification implications.
Supplier OwnerObtain supplier incident information, technical evidence, timeline, containment status, and corrective actions.
Incident CommanderMaintain the investigation timeline and ensure that assumptions, limitations, and evidence sources are recorded.

PURPOSE: To identify root cause, impact, affected systems, affected customers, affected data, duration, and required remediation.
INPUTS: Logs, alerts, tickets, code changes, configuration records, supplier evidence, customer reports, Atlassian records, monitoring records, and system state.
OUTPUT: Investigation findings and impact assessment recorded.
RELATED DOCUMENTS: Vulnerability Management SOP, Software Change Control SOP, Data Breach Management SOP, Supplier Management SOP.

For Marketplace app incidents, Atlassian expects the partner to identify the root cause, whether end user data may have been compromised, how long the issue may have existed, affected users, affected information, containment measures, customer communication plan, remedial actions, and appropriate contact details.

8.5

Preserve and review evidence

Relevant evidence is preserved and reviewed to support investigation, communication, remediation, and closure.

Security LeadIdentify required logs, system evidence, code evidence, and configuration evidence.
Incident CommanderEnsure evidence is preserved before destructive remediation actions are taken, unless immediate containment is required to prevent harm.
Development LeadPreserve code, build, dependency, deployment, and configuration evidence.
Support LeadPreserve customer reports, support tickets, advisory records, and customer communications.
Atlassian Security ContactPreserve Atlassian P1, AMS, ECOHELP, and Atlassian Security communications.
QAConfirm that evidence links are sufficient to reconstruct the incident and the closure decision.

PURPOSE: To maintain record integrity and allow later reconstruction of incident handling decisions.
INPUTS: Logs, alerts, system state, screenshots, code history, support tickets, customer reports, supplier reports, Atlassian tickets, and internal communications.
OUTPUT: Evidence attached or linked to the Security Incident Record.
RELATED DOCUMENTS: Document and Record Control SOP, Software Change Control SOP, Supplier Management SOP.

Atlassian recommends keeping logs for administrative tasks, application errors, application code and configuration changes, and application and related system start-ups and shut-downs, with date and time for each logged event. Locally stored logs are restricted to personnel with an appropriate business need, and access to the logs is itself recorded and monitored.

8.6

Assess PIMS and personal data breach impact

The Privacy Lead assesses whether the incident affects personal data and whether privacy notifications or records are required.

Privacy LeadDetermine whether personal data was affected or may reasonably have been affected.
Privacy LeadDetermine whether Qity acts as controller, processor, sub-processor, joint controller, or independent controller for the affected processing.
Privacy LeadAssess affected data subjects, affected records, risk to individuals, confidentiality impact, integrity impact, and availability impact.
Privacy LeadDetermine whether controller notification, supervisory authority notification, data subject communication, or supplier notification is required.
Incident CommanderLink the personal data breach assessment to the Security Incident Record.
Senior ManagementApprove privacy notifications where required by the Data Breach Management SOP.

PURPOSE: To ensure that PIMS obligations are met and that controller, processor, data subject, and supervisory authority requirements are addressed.
INPUTS: Security Incident Record, investigation evidence, affected data categories, processing role, customer contracts, DPAs, ROPA, DPIA, supplier information, and system logs.
OUTPUT: Personal data breach assessment, privacy decision, notification records, and linked PIMS records.
RELATED DOCUMENTS: Data Breach Management SOP, ROPA, DPIA process, Data Subject Rights process, DPA and Sub-processor Management process.

Where Qity acts as processor or sub-processor, the relevant controller or customer is informed in accordance with the applicable agreement and without undue delay. Where Qity acts as controller, the Privacy Lead determines whether notification to the supervisory authority or to data subjects is required.

8.7

Notify Atlassian

Atlassian is notified and kept informed where a Marketplace app or Atlassian-related incident is confirmed or suspected.

Atlassian Security ContactNotify Atlassian where the incident impacts or may impact a Marketplace app, end user data, Atlassian systems, Atlassian networks, shared secrets, or Atlassian customer trust.
Atlassian Security ContactRaise a P1 incident ticket within 24 hours of becoming aware of a Marketplace app security incident.
Atlassian Security ContactProvide Atlassian with available information on incident type, scope, affected app, affected data, affected customers, containment, remediation plan, root cause, customer communication plan, and contact details.
Security LeadProvide technical details, containment status, root cause analysis, remediation evidence, and verification evidence.
Incident CommanderEnsure Atlassian updates are recorded in the Security Incident Record.
Senior ManagementApprove material statements to Atlassian where legal, customer, or public communication impact exists.

PURPOSE: To meet Atlassian Marketplace obligations and support coordinated incident response.
INPUTS: Security Incident Record, triage assessment, affected app, affected customers, affected end user data, containment status, and investigation findings.
OUTPUT: Atlassian P1, ECOHELP, AMS, or related ticket raised and maintained.
RELATED DOCUMENTS: Atlassian Marketplace Security Requirements, Atlassian Security Incident Management Guidelines, Atlassian Partner Security Incident Response Program.

Atlassian states “when in doubt, report it”, because Atlassian Security will triage and confirm severity.

8.8

Communicate with customers and issue advisories

Customer communication is assessed, approved, issued, and retained where customer impact, data impact, required customer action, or contractual obligation exists.

Incident CommanderDetermine whether customer communication is required or recommended.
Privacy LeadReview communication where personal data may be affected.
Security LeadConfirm technical accuracy of the communication.
Product OwnerConfirm customer impact, product impact, and required customer action.
Support LeadDistribute approved communication and manage customer questions.
Atlassian Security ContactProvide the customer communication plan to Atlassian through the incident ticket where a Marketplace app is involved.
Senior ManagementApprove Customer Advisories, public statements, and high-impact customer communications.

PURPOSE: To provide transparent, accurate, controlled, and timely customer communication.
INPUTS: Impact assessment, affected customer list, affected data, customer obligations, privacy assessment, Atlassian ticket, remediation plan, and required customer actions.
OUTPUT: Customer communication decision, Customer Advisory, customer ticket updates, and communication record.
RELATED DOCUMENTS: Customer Support SOP, Data Breach Management SOP, Atlassian Security Incident Communication Template, DPA and Sub-processor Management process.

Customer communication shall not include speculative statements, unsupported claims, unnecessary confidential information, or statements that no impact occurred unless the investigation supports that conclusion. Atlassian recommends notifying affected customers within 72 hours of identification where possible, and states that partner incident communications should be honest, thorough, and should not try to hide the issue.

8.9

Implement remediation and controlled changes

Technical and organisational actions are implemented to remove the root cause and prevent recurrence.

Security LeadDefine required technical and organisational remediation.
Development LeadImplement code changes, configuration changes, patching, dependency updates, rollback, secret rotation, or release changes.
Product OwnerAssess release impact, customer impact, and required customer action.
QAConfirm whether remediation requires change control, validation, release assessment, or CAPA.
Supplier OwnerObtain supplier remediation evidence where a supplier is involved.
Atlassian Security ContactProvide remediation status and plan to Atlassian where a Marketplace app is involved.
Incident CommanderEnsure all remediation actions are linked to the Security Incident Record.

PURPOSE: To restore secure operation and prevent similar incidents.
INPUTS: Root cause analysis, impact assessment, containment status, affected systems, affected code, supplier information, Atlassian feedback, and customer requirements.
OUTPUT: Remediation actions completed, verified, and linked to controlled records.
RELATED DOCUMENTS: Software Change Control SOP, CAPA SOP, Vulnerability Management SOP, Supplier Management SOP, Risk Management process.

Remediation that affects released software, production configuration, customer environments, validation status, or controlled QMS records is managed through the applicable change control process. Where a vulnerability is identified, the Vulnerability Management SOP is followed and the published remediation targets apply.

8.10

Verify remediation

Remediation is verified before incident closure.

Security LeadVerify that the technical cause has been corrected and indicators of compromise have been addressed.
Development LeadProvide test, review, deployment, rollback, or release evidence.
Privacy LeadConfirm that privacy-related actions and notifications are complete where applicable.
Atlassian Security ContactProvide closure or verification information to Atlassian where a Marketplace app is involved.
QAConfirm that linked change, CAPA, supplier, training, and risk records are complete or have defined follow-up actions.
Incident CommanderDocument the verification outcome and the closure recommendation.

PURPOSE: To confirm that the incident has been contained, the root cause has been addressed, and residual risk is acceptable or transferred to controlled follow-up records.
INPUTS: Remediation actions, test evidence, logs, access review, release records, customer confirmation, supplier evidence, and Atlassian feedback.
OUTPUT: Verified remediation evidence and closure recommendation.
RELATED DOCUMENTS: Software Change Control SOP, CAPA SOP, Vulnerability Management SOP, Supplier Management SOP.

8.11

Conduct post-incident review

A post-incident review is performed for Critical and High incidents, and for other incidents where required by Senior Management, QA, the Privacy Lead, the Security Lead, or Atlassian.

Incident CommanderCoordinate the post-incident review and record findings.
Security LeadConfirm whether indicators of compromise remain and whether logging or monitoring improvements are required.
Privacy LeadConfirm whether privacy actions were adequate and whether the DPIA, ROPA, or DPA records require update.
Product OwnerConfirm product, release, customer, and documentation impacts.
Atlassian Security ContactSubmit post-incident review findings through the Atlassian incident ticket where required.
QADetermine whether CAPA, SOP updates, training updates, or management review inputs are required.
Senior ManagementApprove the post-incident review for Critical and High incidents.

PURPOSE: To identify lessons learned, confirm closure, reduce recurrence, and update QMS, PIMS, product, supplier, or security controls.
INPUTS: Security Incident Record, investigation findings, customer communication, Atlassian ticket, remediation evidence, logs, CAPA records, supplier evidence, privacy assessment, and closure evidence.
OUTPUT: Post-incident Review Record and linked corrective actions.
RELATED DOCUMENTS: CAPA SOP, Management Review process, Risk Management process, Data Breach Management SOP.

Atlassian states that post-incident review should consider remaining indicators of compromise, lessons learned, whether actions reduce recurrence, whether logging needs improvement, and whether external cybersecurity advisers or incident response firms agree that the incident is resolved.

8.12

Close the Security Incident Record

The Security Incident Record is reviewed and closed after required actions, communications, and follow-up records are complete.

Incident CommanderConfirm that all required sections of the Security Incident Record are complete.
Security LeadApprove technical closure.
Privacy LeadApprove privacy closure where personal data was or may have been affected.
Atlassian Security ContactConfirm Atlassian communication closure where a Marketplace app was involved.
QAConfirm QMS record completeness, linked records, and closure criteria.
Senior ManagementApprove closure of Critical and High incidents.

PURPOSE: To ensure that the incident is formally concluded and that residual actions remain controlled.
INPUTS: Security Incident Record, PIMS assessment, QMS impact assessment, Atlassian ticket, customer communication, remediation evidence, verification evidence, post-incident review, and linked records.
OUTPUT: Approved closed Security Incident Record.
RELATED DOCUMENTS: Document and Record Control SOP, CAPA SOP, Software Change Control SOP, Data Breach Management SOP, Management Review process.

A Security Incident shall not be closed by leaving unresolved actions in the incident record without an owner, a due date, and a linked follow-up record.

8. Atlassian communication, in detail

Qity apps run on the Atlassian platform, so an incident affecting an app is also an Atlassian matter. Appendix 1 of the procedure governs that channel.

Contact readiness

Qity maintains Atlassian incident communication information as controlled operational information, through the Marketplace partner email registered on ecosystem.atlassian.net and through security@qity.be. Atlassian requires Marketplace partners to identify at least one security contact email and to have that contact hold an account on ecosystem.atlassian.net, so Atlassian can notify the partner about app vulnerabilities through Atlassian Marketplace Security tickets. The Atlassian Security Contact verifies at least annually that the configured contact route, security contact email, backup contact, and ticketing access remain active.

When Atlassian is notified

Trigger	Requirement
A Qity Marketplace app has been compromised.	Notify Atlassian.
Customer data flowing through the app may have been accessed, exfiltrated, disclosed, modified, destroyed, or manipulated.	Notify Atlassian.
End user data in Qity’s possession or control may have been affected.	Notify Atlassian.
Suspicious Forge app behaviour cannot be explained from Qity’s own logs or monitoring.	Notify Atlassian.
A supply-chain compromise affects the Marketplace app.	Notify Atlassian.
Credible evidence of exploitation is reported by a customer, researcher, supplier, or Atlassian.	Notify Atlassian.
A threat actor is actively exploiting a vulnerability affecting the app.	Notify Atlassian.
A Cloud app issue materially degrades Atlassian systems or networks.	Notify Atlassian.
A Connect shared secret, OAuth token, API token, or signing key may have leaked.	Notify Atlassian and request support, including rotation where applicable.
Qity is unsure whether the event qualifies.	Notify Atlassian or request triage support.

Route and timing

A P1 incident ticket is raised through the Atlassian Ecosystem and ECOHELP support route no later than 24 hours after Qity becomes aware of a security incident impacting a Marketplace app, using the Qity partner account authorised for the Marketplace vendor profile. Where Atlassian has already opened an AMS, ECOHELP, or other ticket, Qity responds in that ticket and links it to the Security Incident Record.

Qity does not rely on an unverified public Atlassian email address for Marketplace security incident notification. The controlled route is the Ecosystem, ECOHELP, or P1 ticket route using the authorised partner account, unless Atlassian gives written instruction otherwise for a specific incident or programme.

What the notification contains

The initial notification includes the information available at the time. Missing information does not delay notification; any unknown item is marked as under investigation and updated when evidence becomes available.

Item	Content
App name and hosting model	The affected Qity Marketplace app, and whether Forge, Connect, Data Center, or Server.
Incident title and awareness time	Short factual summary, and the date and time of first detection or report.
Reporter or source	Customer, Atlassian, researcher, supplier, monitoring, or internal detection.
Incident type	Security compromise, unauthorised access, data exposure, data modification, data destruction, active exploitation, supply-chain compromise, credential leakage, or service degradation.
Incident scope	Affected app, feature, environment, tenant, customer group, infrastructure, integration, or supplier.
End user and personal data impact	Whether each was affected, may have been affected, or is still under investigation.
Customer impact and data types	Known or estimated number of affected customers or tenants, and the categories of data involved.
Incident period	Known or estimated start, detection, containment, and resolution times.
Containment and remediation	Actions taken, actions in progress, and planned remediation with expected timing.
Customer communication plan	Whether customers will be notified, proposed timing, and advisory status.
Root cause and current risk	Known or suspected root cause, and whether the incident is ongoing, contained, remediated, or pending verification.
Contacts and requests	Incident Commander, Security Lead, and Atlassian Security Contact details, plus any requested Atlassian action such as investigation assistance or shared secret rotation.

Update cadence

During active investigation, containment, or remediation of a Marketplace app incident, Qity provides updates at the cadence agreed in the ticket. Where no cadence is agreed, updates are provided at least every 6 hours during active remediation for Critical or High Marketplace incidents. Each update covers current status, new evidence, changes to customer impact, containment, remediation, customer communication, any request to Atlassian, and the expected timing of the next update.

Coordinating customer communication

Where a Customer Advisory is required for a Marketplace app incident, the communication plan is shared with Atlassian through the active ticket. It states whether customers will be notified, the notification basis, the target recipients, the timing and update cadence, the communication channel, the advisory content status, and the required customer action, whether that is credential rotation, update installation, access review, configuration change, monitoring, or none.

Closure communication and records

Where Atlassian notification was required, the post-incident review or closure summary is provided through the active ticket, covering the final incident summary, the timeline from detection to closure, the confirmed root cause and contributing factors, the final end user data assessment, the final customer impact, the communications issued and their dates, the remediation completed, the recurrence controls implemented, any remaining actions with owners and due dates, and the Qity closure decision and approver.

All Atlassian communications are retained or linked in the Security Incident Record: the notification decision and its rationale, the ticket reference, the notification timestamp, the information provided, the status updates, Atlassian requests and Qity responses, customer communication coordination, the closure communication, and the final Atlassian status.

9. Risks this procedure controls

Risk	Control
Security incidents are not reported or are handled informally.	Mandatory reporting, Security Incident Record creation, role assignment, and escalation criteria.
Customer impact continues because containment is delayed.	Severity classification, immediate containment activity, Senior Management escalation, and Atlassian coordination.
Personal data breach obligations are missed.	Mandatory Privacy Lead assignment where personal data may be affected, and a linked personal data breach assessment.
Atlassian Marketplace obligations are missed.	Atlassian Security Contact role, P1 notification requirement, ECOHELP or AMS tracking, and a defined update cadence.
Customer communication is inaccurate, delayed, or incomplete.	Advisory approval, technical review, privacy review, communication record, and content checklist.
Root cause is not addressed.	Root cause analysis, remediation verification, CAPA assessment, post-incident review, and management review input.
Incident evidence is incomplete or altered.	Evidence preservation activity, log retention expectations, controlled records, and access restriction.
Supplier-originated incidents are not controlled.	Supplier Owner assignment, supplier escalation, evidence request, and corrective action assessment.
Remediation introduces product or validation risk.	Linkage to Software Change Control, release assessment, validation impact assessment, and verification evidence.
Recurrence is not reduced.	Post-incident review, CAPA assessment, risk update, logging improvement, training update, and process update.

10. Regulatory compliance matrix

Standard or guideline	Clause or requirement
ISO 13485	4.1 process control and outsourced processes; 4.2.5 control of records; 7.5.6 validation of processes where applicable; 8.2.1 feedback; 8.2.6 monitoring and measurement of product; 8.3 control of nonconforming product; 8.4 analysis of data; 8.5.2 and 8.5.3 corrective and preventive action.
ISO/IEC 27001	Incident management, logging, access control, supplier security, and corrective action.
GDPR	Article 5 principles and accountability; Article 28 processor and sub-processor obligations; Article 32 security of processing; Article 33 notification to the supervisory authority; Article 34 communication to data subjects; Article 35 DPIA review where required.
Atlassian Marketplace Security Enforcement Policy	Documented incident response, prompt investigation, immediate containment, collaboration with Atlassian, P1 notification within 24 hours, customer communication, and post-incident review.
Atlassian App Security Incident Management Guidelines	Containment, Atlassian updates, customer notification, remediation, and post-incident review.
Atlassian Security Bug Fix Policy	Vulnerability remediation timelines and AMS handling.

The complete controlled document, including the severity matrix, is available on request from security@qity.be.