Security Incident Notification.

Effective date: 2026-10-27.

This Security Incident Notification Policy (this "Policy") explains how wrxstack ("wrxstack", "we", "us") responds to security incidents and personal data breaches, and how and when we tell the people and authorities who need to know. It applies to the wrxstack products, including Atlas at atlas.wrxstack.com and Folio, the portfolio and personal-site builder, at portfolio.wrxstack.com, and to the website at wrxstack.com (together, the "Service").

This Policy supplements our Privacy Policy and our Data Processing Addendum (the "DPA"). Where we process personal data for a Customer, section 10 of the DPA governs our breach notice to that Customer, and this Policy describes how we carry it out. If this Policy and the DPA differ on a matter, the DPA controls for that matter. Our Incident response page in the Trust Center describes the same process in shorter form.

The short version

1. Scope and purpose

This Policy covers every security incident that affects, or may affect, the Service or the information it holds, including:

• account data, such as names, email addresses, password hashes, sign-in connections, and preferences;
• content that users and Customers create, upload, or connect in the Service, such as portfolios, documents, files, and records ("Customer Content");
• credentials and secrets used with the Service, such as sessions, API keys, webhook secrets, and tokens for connected services;
• messages sent to us, including contact-form submissions and newsletter sign-ups;
• the systems and service providers that host and run the Service.

Its purpose is to describe how we aim to report, contain, assess, and record incidents consistently, and how we give the notices that the law, or the DPA where it applies, requires.

2. Key terms

Not every security incident is a personal data breach. A failed sign-in attempt, a blocked attack, or a brief outage with no loss of data is a security incident but normally not a breach. We assess each incident under section 6 to decide which it is.

3. Our roles

Our obligations depend on whose data is involved.

• wrxstack as controller. For accounts that people open for themselves, for our own account and communications data, and for website visitors, wrxstack decides how personal data is used. In these cases we notify supervisory authorities and affected individuals where the law requires it, as described in sections 9 to 11.
• wrxstack as processor. For personal data in a Customer's workspace, the Customer is the controller and we process the data on its instructions under the DPA. In these cases we notify the Customer as described in section 8, and the Customer decides whether to notify authorities and individuals, with our help. We do not notify the Customer's users or authorities directly unless the law requires us to, or we agree to a request from the Customer to do so.

wrxstack is an independent product operated from India by its owner. The Service is hosted in the United States. All incident matters are handled through security@wrxstack.com.

4. How to report a suspected incident

Anyone may report a suspected incident: a user, a Customer, a security researcher, a service provider, or a member of the public. Report as soon as you notice something, even if you are not sure it is an incident. A report that turns out to be nothing costs little. A report that is delayed can cost a great deal.

1. Email security@wrxstack.com.
2. Describe what you saw, when you saw it, and which product, page, or account is involved.
3. Include any evidence you already have, such as a screenshot, an error message, or a suspicious email you received. Do not go looking for more data to prove the point.
4. Tell us how to reach you, and whether you want your report kept anonymous in anything we publish.

We aim to acknowledge a security report within two business days. Where a report suggests data is exposed or at risk, we aim to act on it as soon as reasonably practicable after it is read, without waiting to send the acknowledgement.

4.1 Security vulnerabilities

If you have found a vulnerability rather than an incident that is already happening, follow our Responsible Disclosure Policy, which sets out what is in scope, the rules of engagement, and our safe harbor for good-faith research. If you encounter data that does not belong to you while testing, stop and report it at once. We treat that report as a suspected incident under this Policy.

4.2 If you think your own account is compromised

Act first, then report. Where the product offers these controls, change your password, sign out of other sessions, revoke API keys and webhook secrets, and disconnect any sign-in provider you do not recognize. If you signed in with a provider such as Google, Microsoft, or GitHub, secure your account with that provider as well. Then email us so we can check for activity on our side.

5. How we respond

We generally handle a suspected incident in the order below. Steps can overlap, and where data is at risk we aim to contain the incident first.

1. Record and triage. We record the report with the date and time we received it, and decide whether it involves data or security. If it does, we aim to treat it as a priority, as described on our Incident response page.
2. Contain. We take reasonable steps to stop the incident and limit its spread. Depending on the facts, this can include revoking or rotating credentials, ending sessions, disabling an affected feature or integration, blocking access, or taking part of the Service offline.
3. Preserve evidence. We keep the logs and records needed to understand the incident, so far as they exist and our hosting provider retains them, and we take reasonable steps not to destroy information that may be needed later.
4. Investigate. We try to establish what happened, how it happened, when it started, which systems and data were involved, and whose data was affected.
5. Assess the risk. We decide whether the incident is a personal data breach and how serious the risk to people is, using the factors in section 6.
6. Notify. We send the notices that the law or the DPA requires, as described in sections 7 to 12, within the deadlines that law or the DPA sets.
7. Recover. We take reasonable steps to fix the cause, restore normal service, and check that the fix holds.
8. Review. We record what happened and what we changed. We may also publish a summary, as described in section 18.

We do not wait for an investigation to finish before containing an incident or before sending a notice that is due. Where facts are still unknown, we say so in the notice and send further information as it becomes available.

6. How we assess risk

The law ties each notice to the level of risk an incident creates for the people whose data is involved. We assess that risk case by case, considering in particular:

• the type and sensitivity of the data, for example whether it includes credentials, financial details, or information about health or other special categories;
• the volume of data and the number of people affected;
• how easily the data identifies a person;
• whether the data was protected in a way that makes it unintelligible to the person who obtained it, for example strong encryption whose key was not also exposed;
• who obtained the data, if known, and whether their intent appears to be harmful;
• whether the data was only seen, or was also copied, changed, deleted, or published;
• the likely consequences for people, such as identity theft, fraud, financial loss, damage to reputation, loss of confidentiality, or distress;
• how long the exposure lasted and whether it has been fully contained.

We place each confirmed breach in one of three levels: unlikely to result in a risk to people, likely to result in a risk, or likely to result in a high risk. Sections 9 and 10 explain what each level requires. Where we are unsure which level applies, we may treat the incident as the higher one.

7. Who we notify, at a glance

8. Notifying Customers

Where a personal data breach affects personal data we process for a Customer, we notify that Customer without undue delay after becoming aware of it, within the period set in section 10 of the DPA, which controls. The notice includes, to the extent then known, the nature of the breach, the categories and approximate number of people and records concerned, the likely consequences, and the measures taken or proposed to address it, together with the other items in section 13.

We then give the Customer reasonable assistance in meeting its own obligations, as the DPA and the law require, which may include answering its questions, providing the further information it needs for any notice it gives to an authority or to its users, and keeping it informed as the investigation goes on. A Customer that is subject to the GDPR has its own 72-hour deadline to notify its supervisory authority, which runs from when the Customer becomes aware. We aim to send our notice early enough to help the Customer meet it.

Our notice to a Customer is not an admission that the Customer is responsible for the breach, and the Customer's decision about whether to notify others is its own.

9. Notifying supervisory authorities

Where wrxstack is the controller, we notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, not later than 72 hours after becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of people. This follows Article 33 of the GDPR.

• European Union. wrxstack has no establishment in the European Union, so no single lead authority applies. We notify the supervisory authority of each member state where affected people are located, so far as the law requires.
• United Kingdom. Where people in the United Kingdom are affected, we notify the Information Commissioner's Office under Article 33 of the UK GDPR.
• Switzerland. Where people in Switzerland are affected and the breach is likely to result in a high risk to their personality or fundamental rights, we notify the Federal Data Protection and Information Commissioner as soon as possible, as the Swiss Federal Act on Data Protection requires.

If we cannot provide all the required information at once, we provide it in phases without further undue delay. If a notice reaches an authority after 72 hours, it states the reasons for the delay. We would rather send an incomplete notice on time than a complete one late.

If we decide that a breach is unlikely to result in a risk to people and so does not need to be notified, we record that decision and our reasons, as described in section 17.

10. Notifying affected individuals

10.1 What the law requires

Where wrxstack is the controller and a personal data breach is likely to result in a high risk to the rights and freedoms of people, we tell the affected people without undue delay, under Article 34 of the GDPR. The notice is written in clear and plain language. The law does not require this individual notice where:

• the affected data was protected in a way that makes it unintelligible to anyone not authorized to access it, such as encryption whose key was not compromised;
• we have taken later measures that ensure the high risk is no longer likely to materialize; or
• contacting each person would involve disproportionate effort, in which case we make a public communication, such as a notice on our website or status page, that informs people in an equally effective way.

10.2 Notices we may choose to send

Where no law requires a notice, we may still, at our discretion, tell you about a confirmed security incident that affected your account data, your content, or your access to the Service, for example where we think it would help you protect yourself. Any such notice is subject to section 15.

Where your data is in a Customer's workspace, the Customer is the controller and will normally be the one to contact you. If the Customer asks us to send notices for it, we may agree to do so, in the form it approves.

11. United States breach notification laws

Every US state, the District of Columbia, and several US territories have laws requiring notice when certain personal information about their residents is breached. These laws differ in what information they cover, what counts as a breach, and who must be told. Where one of them applies to a breach, we follow it. Depending on the state, that law may require us to:

• notify affected residents in the most expedient time possible and without unreasonable delay, consistent with any legitimate needs of law enforcement and with the measures needed to determine the scope of the breach and restore the integrity of our systems;
• meet any fixed deadline the state sets. Several states set a fixed number of days from discovery, and California, for example, requires notice to residents within 30 calendar days of discovering or being notified of a breach;
• notify the state attorney general or other state agency where the law requires it, for example where the number of affected residents passes the threshold the state sets, and provide any sample notice or report that agency requires;
• notify the nationwide consumer reporting agencies where a state law requires it because of the number of residents affected;
• include in each notice the content that the state law requires.

Where we act as a service provider or processor for a Customer, US state laws generally require us to notify the Customer, which as the owner or licensee of the data then notifies its residents. We notify the Customer within the time set in section 8.

Where more than one state's law applies, we aim to follow the law of each state whose residents are affected.

12. India and other countries

India. Where the directions issued by the Indian Computer Emergency Response Team (CERT-In) under section 70B(6) of the Information Technology Act, 2000 apply to an incident, we report it to CERT-In in the manner and within the period those directions set, which at the date of this Policy is six hours from noticing an incident of a type they list. Once the relevant provisions of the Digital Personal Data Protection Act, 2023 are in force, we notify the Data Protection Board of India and the affected individuals of a personal data breach where, and as, that law requires.

Other countries have their own breach notification laws, each with its own test for when notice is needed and its own timeline. Examples include Canada, Australia, Brazil, Japan, and South Korea. Where such a law applies to a breach, we follow it, including any requirement to notify the authority and the affected people it names, within the time it sets, and with the content it requires. Where this Policy and such a law differ, we follow the law.

13. What a notice contains

A notice generally includes the following information, to the extent it is known when we send it and the applicable law requires it or we consider it useful. Where facts are not yet known, the notice says so, and we aim to send further information as it becomes available, in phases where the law permits.

We aim to state facts in a notice, without speculation, without reassuring language in place of information, and without blaming the people affected. A notice describes what we know when we send it, and we may update or correct it as we learn more.

14. How we send notices

• Email to affected users. Our main channel is email to the address on the affected account. It is sent from a wrxstack address.
• Email to Customers. We notify a Customer at the contact details it has given us, normally the email address of the workspace owner or administrator. Customers are responsible for keeping these details current.
• Notice in the product. Where useful, we also show a notice in Atlas or Folio after you sign in.
• Public notice. Where we cannot reach people individually, or where contacting each person would involve disproportionate effort, we may publish a notice on our website or on our status page, and we do so where the law requires a public communication.
• Authorities. We notify supervisory authorities and state agencies through the method each one prescribes, such as its online breach reporting form.
• Other means the law requires. Where a law prescribes a particular form of notice, such as written notice by post or substitute notice through the media, we use it.

15. Delays requested by law enforcement

A law enforcement agency may ask us to delay a notice because giving it would impede a criminal investigation or endanger national security. Where the applicable law allows such a delay, we may delay the notice. In that case we generally:

• ask the agency to make or confirm the request in writing, and record it;
• delay only the notice the request covers, for the period the agency specifies, and only as far as the law allows;
• continue to take reasonable steps to contain and investigate the incident during the delay;
• send the delayed notice, where it is still required, once the agency confirms that it will no longer impede the investigation or the permitted period ends, as the law requires.

A law enforcement request does not delay a notice to a supervisory authority or to a Customer unless the applicable law permits that delay.

16. Incidents at our service providers

We use a small number of service providers to run the Service, including our hosting provider, listed on our Sub-processor List. A security incident at one of these providers can affect data we hold. These providers' own terms generally provide for them to tell us about incidents that affect our data, and we depend on them doing so. When one does, or when we learn of such an incident in another way, we treat it as a suspected incident under this Policy: we assess its effect on wrxstack data and send any notices that the law or the DPA requires.

Our notice deadlines start when we become aware of a breach affecting our data, which may be some time after the provider itself discovered it. Sign-in providers such as Google, Microsoft, Apple, and Meta are independent companies, and incidents within their own systems are theirs to notify.

17. Records of incidents and breaches

We keep a written record of every personal data breach, whether or not we notified anyone about it, as Article 33(5) of the GDPR requires. For each one, the record states:

• the facts of the breach, including when it occurred and when we became aware of it;
• its effects, including the data and people concerned;
• the action we took to contain and remedy it;
• who we notified, when, and how, or, if we did not notify, the reasons for that decision;
• any law enforcement request to delay a notice, and its terms.

We may also keep a shorter record of security incidents that turned out not to involve personal data. We keep breach records for the period any applicable law requires; Canadian law, for example, requires breach records to be kept for at least 24 months. We aim to include in breach records only the personal data needed to describe the breach, and we make them available to a supervisory authority where the law requires.

18. After an incident

After a confirmed incident, we may publish a summary on our status page describing the cause and the changes we made, where we consider it useful. Whether to publish a summary, and what it includes, is at our discretion, except where a law requires a public communication. We aim to keep any summary free of the personal data of the people affected and not to name a reporter who asked to stay anonymous. Our Incident response page describes the same practice.

19. What we ask of you

• Report promptly. Tell us as soon as you suspect an incident, including any unauthorized access to your account, as our Terms of Service require.
• Protect your credentials. Use a strong, unique password, turn on multi-factor authentication where it is offered to you, and keep API keys and secrets out of shared or public places.
• Keep contact details current. We can only reach you at the email address on your account. Customers should keep the owner and administrator contacts in their workspace up to date.
• Customers meet their own duties. A Customer is the controller of the data in its workspace and is responsible for deciding on and giving any notice to its users and authorities, with our assistance under the DPA.
• Do not store data the Service is not meant for. wrxstack does not sign business associate agreements and is not designed for protected health information or payment card numbers. Do not put them in the Service.

20. No compensation and no admission

This Policy describes how we respond to and notify people about incidents. It does not create any right to a payment, refund, credit, service credit, reimbursement, reward, or compensation of any kind, for anyone, and no such payment arises from a security incident, a notice, or anything else this Policy describes. Liability between you and wrxstack is governed only by the Terms of Service, the DPA where it applies, and the law.

Sending a notice, or describing an incident in a summary, is not an admission of fault or liability. Nothing in this Policy limits any right you have under a law that cannot be limited by agreement, and nothing in it changes any other right or obligation under the Terms of Service or the DPA.

21. Changes to this Policy

We may update this Policy to reflect changes to the Service, to our service providers, or to the law. We will give notice where the law or the Terms require it, and the effective date at the top shows the current version. A change does not alter a deadline the law sets.

22. Legal effect of this Policy

This Policy explains our practices. It is not a contract, and it does not create any contractual obligation, warranty, guarantee, or right for you or for any other person. The only agreements between you and wrxstack are the Terms of Service and, where it applies, the Data Processing Addendum.

Timelines and targets in this Policy are goals we aim to meet, not guarantees, except where a law that applies to us sets a deadline, in which case we follow that law. Nothing in this Policy increases wrxstack's liability. The disclaimers, the limitation of liability, and the other protections in the Terms of Service apply to everything this Policy describes. Nothing in this Policy limits a right you have under a law that cannot be limited by agreement.

23. Contact

To report a suspected incident or ask about this Policy, email security@wrxstack.com. Related documents: Privacy Policy, Data Processing Addendum, GDPR Statement, California Notice, Responsible Disclosure Policy, Sub-processor List, Security, and Incident response.