Security and Data Handling

EA Sphere for Jira Cloud · Effective October 15, 2026

This statement is for the security, privacy and procurement teams that assess Marketplace apps before their organization installs them. It describes how EA Sphere is built and what it can and cannot reach.

Architecture

Access control

The server decides every save and makes one change to a site's data at a time, so changes made at the same moment are taken in turn and none is written over another; storage itself refuses a write that arrives too late. When two people change the same item, the server combines changes to different fields and to different list items, and a save that would replace a value someone else changed in one of a form's main fields after the person opened it is not made until the person has seen that value. A delete the server has answered as done always stands, whole. The details are under Changes made at the same moment.

• Settings are available only to Jira administrators. Every settings change, full replacement of data and deletion of all data is verified on the server against the Administer Jira permission of the person making the request, independent of what the interface displays.
• Notices are addressed to the communication audiences an administrator has configured. Notices to restricted audiences may be recorded only by members of the Jira groups an administrator has permitted for each audience; the server checks this against the person's Jira groups for every notice added and records the sender and time itself. Members of permitted groups may also add individual email addresses; each is counted, stored and named in the change history once, whatever its capitalization, and one containing an invisible character is refused. A notice goes to at most 50 audiences and 50 individual addresses.
• Recorded notices and degradation updates are append-only: the server ignores any attempt to change them and moves the oldest to archive records kept with the degradation when it accumulates many, archiving each update once. They are removed only when their degradation is deleted, and only a Jira administrator can delete a degradation that has notices recorded, or a record any of whose degradations has notices recorded, archived notices included; after a Jira administrator's record delete that stopped part way, the weekly maintenance removes the record's remaining degradations, notices included. When someone other than a Jira administrator deletes a degradation or a tabletop exercise at the moment a notice is recorded on it or it is started, the two are taken in turn: if the notice or start comes first, the delete is refused and nothing is removed; if the delete comes first, the notice or start is not saved and the person is told.
• A degradation is resolved, a recovery exercise ended and a tabletop exercise completed only once: the first stands, a later attempt is refused with nothing of it kept, the person is told that someone else, or they themselves in another window, already resolved the degradation, ended the exercise or completed the tabletop exercise, and no follow-up work items are created for it. An open degradation dialog then shows the degradation as resolved and keeps what the person typed; saving adds it to the resolved degradation, and an update typed there is posted at the Resolved stage. For an exercise, the page may then add the review notes the person typed to the recorded review as a separate edit, within the 20,000-character limit, and, for a tabletop exercise, their objective results where none had been chosen, so results someone else chose are never taken for none chosen. While a dialog waits for its change to be recorded, all its buttons wait too and say why when selected. A resolution or end sent again after a lost connection is recognized as the person's own. Ending a recovery exercise is refused if someone has just marked the exercised system's step restored, so that the end is made on the latest copy. Once a recovery exercise has ended, its steps cannot be changed. Review notes and observations are never cut short: a review or observations longer than 20,000 characters are refused with a message. When two people change the same text of a review from the same copy, the later save is refused and the person is told; text each of them only added at the end is kept.
• A Jira work item can be referenced in EA Sphere only by someone who can see it in Jira; the server confirms this with that person's permissions and takes its summary, status and due date from Jira rather than from the browser. Each Jira work item can be referenced once; a work item kept only in EA Sphere cannot take a Jira work item's place, and a stored work item is never linked to a different Jira work item. When records and change history are loaded, the server withholds the key, summary, Jira status and due date of any referenced work item the viewer cannot see in Jira; change history names it as a restricted work item, and it is listed among open or done work items without those details. While Jira is limiting requests, details Jira has not confirmed within about seven seconds are withheld in the same way until the next load.
• The server adds each change history entry and sets its account and time itself. The description of a change made on a page comes from that page; EA Sphere writes the description of the changes it makes itself, such as those from Jira, the weekly maintenance and a work item's effects on records. Entries cannot be edited. Each record keeps up to its latest 200 changes. Changes older than the retention period an administrator sets are hidden at once and removed by the weekly maintenance. When a record is deleted, its change history is deleted with it; its entries leave the Change log report at once and are removed from the site-wide log by the weekly maintenance.
• EA Sphere also writes a Stage line whenever a save changes a record's stage, with the write that changes it and from what it stores, attributed to the person whose save changed the stage, including a save that marks a work item kept only in EA Sphere as Done, or to EA Sphere when the change comes from Jira, such as a Jira work item being done, or from the weekly maintenance. The person's own change, Jira's part of a save and a work item's Done, Delivers and Retires effects each write their own line, so a record's Stage lines form one chain, each starting where the one before ended and the last ending at the stage shown, even for saves made at the same moment or a save of dates that meets Jira's Done; a save whose own change and its work item's effect cancel out writes no Stage line. A Stage line repeated later for a new change is written again; only a retry of the same change reuses its line. The one exception to the chain is a stage reached only because a date has passed, such as Planned to Active on the in-service date: it is not recorded as a change, and the next Stage line starts from that stage.
• Records that carry their own history, authors and times are accepted only from the Jira administrator who deleted all data, within 30 minutes of that deletion, and never overwrite a record that already exists. EA Sphere uses this only to load the sample data set when an administrator replaces all data with it.
• The server applies a work item's effects on records, Retires and Delivers, with the work item save itself, whether a person saves it or a Jira event updates it; a reference to a single module never changes the record. When a work item is marked Done, its effects are applied once to every record it references, including references added afterwards, dated the day it was marked Done, with one Retired by or Delivered by line. A Jira event takes its turn with people's saves, waiting up to 15 seconds; one that still cannot begin is left to Jira's next event for that work item, the next page to read the work item from Jira, or the weekly maintenance, which applies Done where it was not applied. A reference removed before the Done is not retired or delivered by it, and is worked out as that person's own change, counting only the work items they can see in Jira; the mark that the effects were applied is stored in the same operation as the last of the records they change, so it is never set while a record is still to change; if storage refuses part way, the rest is applied like any effect still to apply, and no record is changed twice.
• A work item whose save stands while storage refuses some of its records' Referenced by or Reference removed lines has those lines noted with the save, and they are added like effects still to apply, shortly afterwards or by the weekly maintenance, each with its own time and person, in its place in the history and with its Change log entry; a save sent again writes none twice. Effects still to apply are kept until they are applied, for the person whose save left them: a page is told only of its own person's, and finishes only those. When effects do not fit in one request, the page asks the server to finish them straight away, up to five times, and again at each refresh while any are left (the work item panel, which does not refresh, asks again by itself, less often each time), and until they are applied it warns before it is closed; a page on a site whose license is not active does not try to finish them. Any still left, for example because the page was closed, are applied when Jira next sends an update event for those work items, or by the weekly maintenance, which checks every record's planned retirement date and awaiting-delivery mark against its work items; both first apply any Done not yet applied, and until then a work item marked Done still holds the record's planned retirement date. The weekly maintenance also checks work items already marked as applied and puts back a Done that a save carried back, without adding a history line and without overriding a planned retirement date set after the Done.
• The server decides whether a record is awaiting delivery; a page cannot set it. A planned retirement date taken from work items is always the earliest due date among the open work items that retire the whole record, and a date set by hand is never changed by work items' due dates, only by a Retires work item being done. A Retires reference added to a work item already done, or a work item first stored already done, for a record already retired or past its planned retirement date, keeps the earlier date and writes a Stage line only if the stage changes. A Jira work item reopened after its Done was applied no longer holds its record from retiring.
• A record's planned retirement date and awaiting-delivery mark count every work item linked to the record, including work items some people cannot open in Jira; those people still never see such a work item's key, summary, Jira status or due date in EA Sphere's work item views, although the record's planned retirement date may be that due date. A person's own save never changes the date because of a work item they cannot open. Changes that come from Jira, and the corrections the weekly maintenance makes, count every work item and are recorded as made by EA Sphere, not by the person whose page recorded them; in a save that carries both a due-date change from Jira and the person's own change to the references, Jira's part is worked out from the work items as they were before the person's change, and each is attributed accordingly. Only someone who can see a Jira work item in Jira can change which Jira work item a reference points to, or which records it references; the exceptions are that deleting a record removes the references to it from every work item, and that anyone can remove a work item from EA Sphere, which leaves the Jira work item unchanged.
• Removing a work item from EA Sphere, whether it is a Jira work item or one kept only in EA Sphere, writes a Reference removed line, credited to the person removing it, in every record it referenced, once the removal stands: a removal storage refuses writes none, lines storage refuses are added shortly afterwards like effects still to apply, and none is written twice: a removal sent again after part of it failed writes one line per record, naming the work item. A save that removes a work item counts as finished only after its last history lines are written, so a colleague's history line written meanwhile stands. Removing one the person cannot see in Jira never changes a record's planned retirement date or awaiting-delivery mark from their save; the weekly maintenance, which counts every work item, works them out again; so does Jira's next update event for another open work item that references the whole record: for the planned retirement date when it retires the record, and for the awaiting-delivery mark when it delivers it.
• A reference to a record that no longer exists is left out of a save, and the person is told; a degradation or exercise cannot be started for such a record, and a new work item whose every referenced record has been deleted is not added. A reference to a record someone else has just created under the same name is pointed at that record; for a work item, its Referenced by line is written in that record's history. A save that still sends a recovery tier or communication audience removed in Settings since the page read it keeps the record's stored tier and leaves the audience out, saves the rest, and tells the person, naming them. A recovery tier or a communication audience still assigned to records cannot be removed in Settings, whatever a page shows: the server refuses the save and names up to three of the records.
• Record names are stored without invisible formatting characters, bidirectional controls included, keeping only the zero-width joiners and non-joiners between letters of scripts written with them (never between Latin, Greek or Cyrillic letters), the joiners inside emoji and the emoji presentation selector, and are unique, compared without regard to case, repeated or surrounding spaces, any invisible character or full-width forms; the server enforces this when two people create the same name at once. List values, severity levels, audiences, sender groups, recovery tiers and change freezes in Settings are stored and compared the same way, and a name listed twice is refused with a message naming it; when two administrators add an audience, severity level, sender group or recovery tier of the same name at the same moment, the later save is refused unless the details are the same, in which case it is kept once. An incident role may be listed more than once; each row is kept as its own row, so a change to one row never lands on another, a row repeated exactly is kept once, and a role named again in another case or spacing takes the first row's spelling. Values a person types in a record or degradation that match a list value apart from case, spacing or hidden characters are stored in the list's own spelling.
• A value renamed in Settings, including a rename that changes only capitals, spacing or hidden characters, is moved to its new name by the server, as part of accepting the settings, in every record, degradation and acknowledgment that holds it; work it cannot finish at once is finished right after, by the next save or by the weekly maintenance, with each record's line credited to the administrator who renamed the value and written once; a record anyone saves while the move is under way gets one rename line, credited to that administrator, never to the person whose save carried it. Until that work is finished, a settings save that adds the old name again, or removes the new name, is refused, as is a save that renames a list value or severity level and adds its old name again. While the work is under way, the server compares saves under the new names, so a renamed value a person removes from a record stays removed, and a renamed value a person changes, such as an owner, a data type or a degradation's cause, keeps the person's change with their history line.
• Deleting a record is a single save carried out on the server, and if removing its references runs out of time, EA Sphere finishes the removal shortly afterwards, with one history line per record: the record's change history, degradations and recovery exercises are deleted with it, archived updates and notices included, and references to it are removed from every other record and every work item, including work items the person cannot see in Jira; tabletop exercises are kept and show the record as deleted. A refused delete changes nothing.
• Acknowledgments and knowledge checks are written only by the person they belong to, including when an administrator replaces all data; the server rejects any other write, except that a Jira administrator can remove a person's acknowledgment record; an acknowledgment of a briefing for a team or incident role no longer in Settings is refused. The server sets the completion time itself, so records cannot be back-dated. A knowledge check is recorded only when the answers submitted are all correct, checked on the server. People other than Jira administrators receive only their own acknowledgment record.
• The server sets the times a tabletop exercise starts and ends. Once an exercise has started, its plan cannot be changed and only a Jira administrator can delete it; once it is completed, the server accepts changes only to its review and objective results; and an exercise cannot be returned to an earlier state. An edit to a development or an objective someone else has removed is refused, as is an edit to a recovery exercise step someone else has removed. Each facilitator's notes are a separate record that only that facilitator can write, while the exercise is running and for 15 minutes after it ends. The server checks the structure of every exercise it stores.
• The coverage report and the Jira group membership it reads are available only to Jira administrators, verified on the server. Group membership is not stored.
• When the app's license is not active, the server refuses changes, except that a Jira administrator can still delete all data; Jira work item events leave records unchanged, and the weekly maintenance does not apply work item effects, move renamed values or work out dates again; and the interface is read-only.

Changes made at the same moment

• One change at a time. Every change to a site's EA Sphere data holds a site-wide lock while it reads what it changes and writes it: a person's save, the work item effects a page asks the server to finish, deleting or replacing all data, a Jira event for a linked work item, and each turn of the weekly maintenance. Changes made at the same moment are therefore taken in turn, each made on the data as the one before left it, and never written over one another; the second normally waits a fraction of a second. The lock is a record of its own in the app's Forge storage, taken and given back with conditional writes, so two requests can never both hold it; one left by a request that stopped lapses on its own after 30 seconds.
• Storage refuses a late write. Every write made while holding the lock is checked by storage, in the same transaction, against the lock: a write from a request that ran out of time, arriving after the lock has passed to another change, is refused by storage itself and never lands over newer data. Such a change is stopped with nothing written after that point, and the person is told “EA Sphere could not finish this change in time, so it was stopped. Reload to see what was saved, then try again.” This needs storage to be slower than a request may run.
• A save that cannot have the lock within about 8 seconds writes nothing and answers that EA Sphere is busy. The page sends it again by itself for about half a minute, showing Saving…, and only then tells the person “EA Sphere is finishing another change. Yours has not been saved yet; try again in a moment.” Deleting all data, and replacing it with the sample data set, are sent again in the same way. The weekly maintenance works in turns of at most 15 seconds, with a pause between turns so that people's saves go first.
• Each time all data is deleted, the server starts a new data generation: a page opened before it cannot save, and reloads. When two people change the same record, work item, settings or exercise, the server combines their saves: changes to different fields, and items added to or removed from a list, are all kept, each with its history line. Lists are combined item by item: a record's upstream dependencies, hosts, data types, business functions, modules, audiences and support types, a work item's references, a tabletop exercise's developments and a recovery exercise's steps. If two people add the same Jira work item at once, both people's references are kept, with one set of history lines. A save that fails gives up at once the record names it was holding.
• A save that would change a field someone else changed after the person's page read the record, to a different value, is not saved, so nobody overwrites a colleague's change without seeing it. The form keeps what the person entered, shows the value now saved under that field with a Use the saved value button, and says, for example, “Owner was changed after you opened this. The saved value is shown under the field; save again to keep yours, or use the saved value.” Saving again keeps the person's value; using the saved value keeps the colleague's. The fields compared are, for records, name, type, owner, primary contact, version, in-service date, planned retirement date, vendor end of support, support notes, recovery tier, environment, hosting model, recovery sequence step, vendor, vendor support site, vendor support phone, contract reference, support portal, support contact and on-call line; for degradations and recovery exercises, severity, reason or root cause, related change, summary, scenario and participants; for tabletop exercises, title, type, scheduled date, facilitator and participants; and for work items kept only in EA Sphere, title and due date. A value renamed in Settings is compared under its new name. For start and end times, stages and other single values, such as a development's title or text, an objective's text or an exercise step's label, the later save stands, with its history line; ending, and two edits of the same review text, have their own answers, described above.
• EA Sphere's own changes to records and work items, such as applying Jira's details, Done, Retires and Delivers, moving a renamed value, or the weekly maintenance's corrections and its removal of references to deleted records, take their turn in the same way and are made on the copies as stored, so each change, a person's or EA Sphere's, keeps its own history line.
• EA Sphere stores each record together with its history and Change log entries in one all-or-nothing storage operation, whether a person's save or one of EA Sphere's own changes writes it: a record, degradation or notice whose history cannot be written is not stored, and the person is told it was not saved. A save larger than one such operation, such as a CSV import, a work item that references many records, or a change to many records at once, is written in several; each record stands or falls with its own history, so if a later part is refused, the records written before it keep their lines, and the person is told the save was not completed: bulk add and CSV import say how many records were stored, and the record form says whether the record itself was and names the downstream dependents that were not; colleagues see the stored part at their next refresh. Saving again, or EA Sphere's next pass, finishes it, and a save's own retry never overwrites a colleague's change made between its parts, nor creates again a record someone deleted meanwhile, which every later attempt is told was saved, then deleted by someone else. A save is never sent again from an earlier read over someone else's later save, a failed save never reverts a colleague's change, and a save sent again after one that was not stored is treated as a first attempt.
• A record's history lines are written in the same operation as the record, so a refused write leaves neither; when a change is refused part way, a later attempt keeps the records and lines the earlier one wrote, so each change has one line. EA Sphere's own changes to many records are made in parts of up to 300 records, and no rename line is written twice.
• A save to a record deleted meanwhile is refused rather than bringing the record back, and a delete the server has answered as done always stands, whole: the deleted item is never stored again, and the deleted record's name can then be taken by one record only. A save of a deleted record, of a degradation, recovery or tabletop exercise for it, of a deleted degradation, recovery exercise or tabletop exercise (exercise notes included), or of a deleted work item, a Jira-linked one included, is refused as deleted by someone else.
• A save sent again after a connection error carries its own identifier, is recorded once, never overwrites a later change by someone else and never brings back something deleted after its first attempt; a degradation or exercise start, update or notice is read from the server before it is sent again, is never recorded twice, and is not sent again when the server cannot be reached to check. The server tells a person whether one of their own saves was recorded, and never reveals anything about another person's saves. A new record, work item, degradation or exercise whose save gets no answer is read back from the server at once, and read again before it is sent again, so it is never created twice; a record or work item found recorded is then saved with only the person's changes since, so changes others made to it meanwhile are kept. Two or more starts of a degradation for the same system made at the same moment are all recorded, and a person whose start finds the others is told.
• Notices, updates and acknowledgments recorded while a rename is being moved are never dropped by the move, whether or not older updates are archived meanwhile, and none is lost or kept twice; a degradation resolved meanwhile keeps its resolution, under the new names, and an acknowledgment recorded while a team or role is renamed is stored under the new name, so a team created later under the old name never counts the person as a member or credits them with its briefing. Renames are also applied to saves from pages opened before them, acknowledgments keep their completion dates, and a name renamed and later added again is a new value to which nothing is moved.
• The record itself is removed first and its change history and degradations after it, so a delete that stops part way never leaves a record without its history: if the record's own removal is refused, nothing of it is deleted and the Change log report still shows it; if the delete stops after it, because storage refuses or time runs out, every open page is told at once to drop the record and its degradations, the person is told it was deleted, an edit to one of its degradations or exercises is refused as deleted by someone else, and the delete sent again, or failing that the weekly maintenance, removes what is left, including its degradations with any notices recorded (only a Jira administrator can delete a record whose degradations have notices) and the references to it from other records and work items, each of those records getting a history line by EA Sphere. The weekly maintenance keeps the Change log entries of every record that is still stored, and keeps a deleted record's marker, which keeps its history out of the Change log report, while any degradation still names the record.
• A degradation, recovery or tabletop exercise added for a record, a notice or update added on one of its degradations, a degradation moved to or from it, or a reference to it, made at the moment the record is deleted, is taken in turn with the delete. Made first, it is handled by the delete like everything else the record has: a degradation or recovery exercise is deleted with the record, unless a degradation has a notice recorded and the person deleting is not a Jira administrator, in which case the delete is refused; a tabletop exercise is kept and shows the record as deleted; a degradation moved to another record stays on that record; and a reference is removed with a history line. Made after, it is refused, and the person is told that the record was deleted by someone else; a reference is left out of the save, and the person is told.
• The weekly maintenance removes any degradation left without its record (one with notices recorded only when it was left by a Jira administrator's record delete that stopped part way), after checking it again just before (one moved to a stored record meanwhile, even while the maintenance runs, is kept), any archived updates left without their degradation, and any references that remain from records not changed in the previous 24 hours; references in records changed since are removed on a later run if they still point to a deleted record.
• A recovery tier or communication audience removed in Settings while a record form is open is no longer offered once the page has read Settings again; one the person had chosen is shown as removed in Settings. A save that still sends one keeps the record's tier and leaves the audience out, saves the rest, and tells the person, naming them. A recovery tier or audience that a record uses cannot be removed in Settings; the server refuses the removal and names the records.
• When the same Jira work item is linked to two different EA Sphere work items at the same moment, the second link is refused, as when the first has already been saved.
• A change the server has confirmed as saved is not lost afterwards, and no degradation with a notice recorded is left on a deleted record once the weekly maintenance has removed what a delete that stopped part way left. Every record delete, an administrator's included, checks the record's degradations again just before removing it: one saved for the record meanwhile is deleted with it, unless it has a notice recorded and the person deleting is not a Jira administrator, in which case the delete is refused.

Permissions requested

Data handling

• EA Sphere stores Atlassian account IDs to attribute changes, verifications, notices, degradation updates, tabletop exercises, the ending of degradations and exercises, exercise notes and renames still being moved, and to record acknowledgments. It does not store names, email addresses or avatars from Atlassian profiles. Names, email addresses and telephone numbers that users type, such as contacts, facilitators, participants, audience addresses and additional notice recipients, are stored as entered.
• The server keeps a list of the account IDs that appear in the data, and of every person whose save wrote or deleted anything, with the date each last acted, and reports them to Atlassian's personal data reporting service weekly. Closed accounts are erased from all records, change history, degradations, exercises and exercise notes, and from the note of renamed values still being moved, whose remaining history lines are then credited to EA Sphere; their acknowledgment records are deleted. The weekly job resumes where it stopped if a large site needs more than one run.
• The erasure of closed accounts takes its turn with people's saves like any other change, so a change saved meanwhile stands, and runs once for each closed account: no save can write an erased account ID back. A run erases at most 2,000 accounts; any more are erased the following week.
• Each save is noted for an hour, or longer while its effects on other records are still to apply, with a one-way digest of the saving person's account ID, so that a save sent again is recognized and only that person can ask whether it was recorded or complete it. Each save's writes also carry a short tag of the save, a one-way digest from which neither the save nor the person can be read, so that whether a save was recorded can be told after that note has gone.
• A record deleted shortly after it was written leaves a note, for an hour, of its identifier and the identifiers of those writes, with no personal data, so that a save sent again never creates it again. History lines noted with a save of a work item, with the saving person's account ID, are kept until they are added, and the erasure of closed accounts reaches them. EA Sphere also notes under each record the identifiers of degradations and recovery exercises saved for it in the last minute, so that a start made a moment after another is told of it and a delete of the record finds them; such a note is removed when its degradation is deleted, moved or refused, and older notes are ignored and cleared. The weekly maintenance removes any of these notes more than an hour old. The lock that makes changes one at a time holds no personal data: a random ticket, the name of the kind of change holding it, a time and a counter.
• Administrators can export all data as a JSON file, and delete all data from the app, at any time.
• Error logs are written without record content. Renevell can see them, through Atlassian's developer console, only while the customer's site shares app logs; site administrators can turn log sharing off in Atlassian Administration, under Apps, Sites, your site, Connected apps, EA Sphere, Details, Logs access.
• Renevell has no access to the records customers store in the app.

Input validation

The server accepts writes only to known collections, with validated identifiers and size limits, checks every record against the fields, types, counts and dates expected for its kind (a work item, for example, references at most 50 records, and every date must be a real calendar date or time), shortens text longer than a field holds (a record name, for example, to 120 characters), and answers a malformed request with a validation error. A save that would take one of a record's lists past its limit, including one made by combining two people's changes, is refused with a message; no list is cut short. Responses are kept within the platform's size limits and are read in pages where needed. Each write in a batch is checked on its own and a refused write is reported with its reason. All values shown in the interface are escaped before rendering, and exported spreadsheet cells that begin with a formula character are written as text.

Reporting a vulnerability

Report suspected vulnerabilities to support@renevell.com, with "Security" in the subject. We acknowledge reports within two business days and fix confirmed vulnerabilities within the timeframes Atlassian sets for Marketplace apps. Please do not test against Jira sites you do not own.

Related documents

Privacy policy · Terms of service · Data processing addendum · Support · Documentation