This page will tell you everything you need to know about security, privacy, data handling, and compliance. If you can't find what you need in the FAQs, contact us any time for a quick answer to all of your questions.
Do you have a user access approval process in place? If so, how is user access governed and granted for users who have access to the OS, DB, or whatever constitutes a service that the application runs on or integrates with? (i.e., is access based on job description and/or responsibility?)
draw.io is 100% integrated into Confluence, so it can't be accessed independently. Your users have access to draw.io once they signed/logged in to Confluence. Access to diagrams is handled via the Confluence permission settings. So if users don't have permission to a specific space or page, they won't be able to view or search for any diagram. draw.io diagrams are saved to Confluence, so data is saved to the same database as Confluence content. User authentication is not handled by draw.io.
Do you have a process in place that ensures user login IDs, that have OS, database, application access, are disabled in a timely manner (e.g., within 1 hr, 12hrs, or 24 hrs, etc.)? And if so, when is access removed subsequent to employee termination?
Not necessary, as draw.io is 100% integrated into Confluence and can't be accessed within being signed/logged in to Confluence (see answer above).
Do you have a process in place that ensures segregation of duties (e.g., the requester is not the approver, etc.)? How is privileged access approved? (i.e., Is access approved by authorized personnel?)
draw.io follows the Confluence permission settings (see answers above), so accessing/editing/creating diagrams is bound to every user's page/space or global permissions. This question does not apply to our app.
Do you have a process in place that logically partitions our data from other customer data? Does each customer have their own database and/or subnet (only applies to Confluence Cloud, as draw.io for Confluence Data Center and Server are running behind your firewall)?
The editor of draw.io runs in your browser and loaded with the diagram from your Confluence Cloud instance. The final diagram is saved to your Confluence Cloud instance. So there is no need to logically partition your data from any other customer data, as all of our customers save their diagrams to their Confluence environment at any time. Atlassian Cloud handles the saving and storing of diagrams.
Do you have a change management process in place? If so, what are the process control requirements?
We aren't running a defined change management process. Instead, we are a customer demand-driven company, enabling our users to suggest new features and changes to our tool (see our public Github repository). If requests get enough votes from the community, are relevant, and fit our strategic goals, we will check if the feature can be implemented and eventually start building it.
Do you have access to our instance of the application and/or data? If so: Is your vendor access removed upon application go-live? What is the timeline when your access is removed? Is there an elevated support period or ongoing support access that is governed by us?
We don't have access to your data, as all of your diagrams are stored in Confluence (see answers above). A few services can't run in your browser (such as PDF creation and a few import functionalities, this only applies to draw.io for Confluence Cloud) that require a separate server. Please have a look at https://drawio.link/datagovernance for details. You can enable our data governance feature to ensure that the server is located in the same data Center as your Confluence Cloud instance. Furthermore, you can even disable the features to limit the endpoints to your browser and Confluence Cloud. When using our external server for rendering, e. g. a PDF file, your data is (of course) always encrypted, securely transmitted, and deleted from the server, once it has been provided to you.
Do you perform static and dynamic scans on updated code? If vulnerabilities are identified, how are they remediated in a timely manner?
Detectify is used for automated web app scanning. Vulnerabilities go into Jira with a specific security tag that starts an SLA process for that ticket and escalates automatically.
What do you use for system hardening across your various assets (i.e., servers, workstations, mobile devices)? What benchmarks, if any, are being used?
Do you have an established process in place for security patch management for their application? If so, what is the established frequency of the security patch deployment (i.e. Quarterly, Annual, etc.)?
We are running a continuous process when it comes to security patches. Once the need for a patch is discovered, we are working on a fix and automatically roll it out to your draw.io for Confluence Cloud subscription (no need to install a patch). For draw.io for Confluence Data Center and Server, you need to update draw.io to install the patch. There is no established frequency, as we roll out patches once there is a need for it. But we usually update draw.io every two weeks.
Do you have a process in place for vulnerability management? If so, have you defined a vulnerability remediation methodology based on severity (i.e., time frame of remediation per severity ranking, etc.)?
Please have a look at paragraphs 12-14 of our end user license agreement for draw.io. You can always contact us via the support channel that you find under paragraph 9.2. Furthermore, we are part of Atlassian's Bug Bounty Program, a tool that focuses on crowdsourced vulnerability discovery. This way, we can discover and fix vulnerabilities continuously and make draw.io more secure each day.
Do you have a process in place for encrypting sensitive data that is at rest and in-transit (i.e., disk, database, URL parameters, only applies to draw.io for Confluence Cloud)?
Data is encrypted during all network transmission to and from the endpoint. Storage is handled by Atlassian Cloud which also offers encryption at rest and in-transit. All customer data stored within Atlassian cloud products and services is encrypted in transit over public networks using Transport Layer Security (TLS) 1.2+ with Perfect Forward Secrecy (PFS) to protect it from unauthorized disclosure or modification. Data drives on servers holding customer data and attachments in Jira Cloud and Confluence Cloud use full disk, industry-standard AES-256 encryption at rest.
How do you ensure that draw.io is continuously working on the security of their Atlassian apps and closing security gaps?
We are part of Atlassian's officialBug Bounty Program, which supports app vendors in detecting vulnerabilities in applications and services. Atlassian partners withBugcrowd, one of the leading crowdsourced security platforms. Bugcrowd uses the collective creativity of a global hacker communityto discover and fix software vulnerabilities. In addition to the official Atlassian program, we naturally always take care to prevent bugs from occurring in the first place. Furthermore, we are in a continuous exchange with our users and offer the possibility to report bugs quickly and easily via our Github repository.
Where is my diagram data stored in Atlassian Confluence and Jira? How about third party servers or usage tracking?
draw.io for Confluence and Jira (Server/Data Center)
Your draw.io data is exclusively stored on the server that you are using to run your Confluence or Jira deployment.No diagram data ever gets tracked or saved to a source outside your deployment or used by one of our servers or third party services. In the default setup, no diagram data is ever sent externally under any conditions. There is an option to connect to an external image generation server to improve font support the draw.io PDF export. Note that this is disabled by default and PDF export is still available by default, just with limited font support.
draw.io for Confluence and Jira (Cloud)
Your user authentication is only stored in your browser. Saving/loading your diagrams is directly between your browser and Atlassian's servers,these operations do not transit through third-party servers.All of the primary data stored in your Confluence and/or Jira instance will reside on servers in your chosen region due toAtlassian's data residency policy.
A few extended features (export to pdf, import of .vsd, .vss and .vsx files, Gliffy import and generating diagrams from PlantUML) can't be performed within your browser. When using these features, thedata is sent securely to the draw.io server endpoints. Data is encrypted during all network transmission to and from the endpoint. Once it has been successfully returned, all data is deleted from our servers, nothing is persisted. In the draw.io standard plans for Confluence Cloud and Jira Cloud, we’ve implemented the data governance option, which lets you specify the draw.io server endpoints region. → How to define endpoints
Using the draw.iolockdownoption, you can additionally restrict data transmission toonlybetween your browser and your Confluence Cloud instance (and effectively disable the features described above).
Linking to diagram data outside of Atlassian deployments
draw.io offers to embed existing diagrams from the web service/desktop solution diagrams.net. These diagrams will only be linked to the Confluence page if you manually choose so. There is no possibility to edit the diagram with the Atlassian deployment. It's a view only mode for cloud-based diagrams from Google Drive or other cloud hosting services. If you like to embed these diagrams into Confluence, drag and drop the XML files on a blank drawing canvas.
Does draw.io meet ISO/IEC standards?
Because your diagram data is not shared or stored outside of your device and the platform where you save your diagram, draw.io can help you achieve certification under the ISO 27000, 27001 and 27002 standards, the three worldwide standards that cover data protection.
Along with the comprehensive and integrated Confluence revision history, your draw.io diagrams will help you get certified under ISO 19011 (auditing and quality management systems).