Generic security questionnaire

Last updated: July 2026

Applies to: Free, Pro, and Teams plans (self-service)

Maintained by: Iterating Inc. — support@epanetjs.com

How to use this document

This document answers the security and privacy questions that utilities and engineering firms most commonly ask about epanet-js. It is intended to help your team complete its own internal security review and vendor assessment forms for our self-service plans.

Scope note: This document describes epanet-js in its standard, local-first configuration, which is how all self-service plans operate. Cloud project sync is opt-in on a per-project basis and is currently available to a limited set of invited organizations; we work with those organizations directly on their security reviews. Organizations that want a hard guarantee can disable all cloud functionality across their accounts (see section 2). We will update this document when cloud workspaces become generally available. Enterprise configurations (customer-managed storage and on-premises deployment) include a completed security questionnaire as part of onboarding — contact sales@epanetjs.com.

If a question your organization needs answered is not covered here, email support@epanetjs.com or book a call at https://cal.com/epanet-js/.

1. Company information

Q: Who is the legal entity behind epanet-js?

Iterating Inc., a Canadian provincial corporation (Ontario) with its registered office at 2967 Dundas St W #536, Toronto, Ontario, M6P 1Z2, Canada. Iterating Inc. owns and operates the domains epanetjs.com, masteringwater.com, and iterating.ca.

Q: Who is the primary security and privacy contact?

support@epanetjs.com for security questions and vulnerability reports. support@iterating.ca for privacy and data-subject requests.

Q: In which jurisdiction is the company established?

Canada. Canada is recognized by the European Commission as providing an adequate level of data protection under GDPR.

2. Product architecture and data flow

Q: What is epanet-js?

epanet-js is a browser-based hydraulic modeling application for water distribution networks, built on the open-source EPANET simulation engine compiled to WebAssembly.

Q: Is epanet-js a cloud application? Where is our data processed?

In its standard configuration, epanet-js is a local-first application, not a cloud application. The browser acts as a secure runtime, much like a desktop operating system: when the app loads over HTTPS, the entire application — including the simulation engine — downloads to the browser cache and runs on the user’s own CPU and memory inside the browser sandbox.

Hydraulic models, network layouts, simulation results, and any customer data embedded in them are created, computed, and saved entirely on the user’s machine. This data is never uploaded to, transmitted through, or stored on Iterating Inc.’s servers.

Q: What data does leave the user’s machine?

Only account and product telemetry data (see sections 4 and 6): login credentials handled by our identity provider, payment details handled by our payment processor, and product usage analytics. Model files and their contents are never transmitted.

Q: Can the application work without an internet connection?

Yes. An internet connection is required to load the application initially. Once loaded, the user can disconnect entirely and continue creating models, running simulations, and saving files. This can be verified directly by disconnecting from the network after the app loads.

Q: Where are project files stored?

On the user’s hard drive or network drive, as ordinary files — the same pattern as traditional desktop modeling packages (InfoWorks, WaterGEMS, InfoWater). Files are shared through your organization’s existing channels (email, shared drives, portable media), so your current file-handling and security policies apply without modification. No new data pathways are introduced.

Q: Does the browser get access to the user’s whole file system?

No. epanet-js uses the browser’s File System Access API. When a user opens a project, the browser presents the native system file picker, and the application receives read/write access only to the specific file or folder the user selects. It cannot see the rest of the hard drive, the operating system, or network shares.

Q: Do you offer cloud sync, and how does it affect this assessment?

Cloud project sync exists as an opt-in, per-project feature and is currently in limited availability with a small number of invited organizations, whose security reviews we handle directly. For all other users, no cloud sync is in effect, and enabling it is not possible without our involvement. Projects that are not cloud-enabled remain 100% isolated on the user’s machine.

Q: Can our organization guarantee that model data can never leave our machines?

Yes. Organizations can disable all cloud functionality across their accounts. With cloud disabled, no mechanism exists in the product to transmit model data to our servers — the guarantee is architectural, not policy-based, and it can be verified in the public source code. To disable cloud functionality for your organization, contact support@epanetjs.com.

3. Customer and infrastructure data handling

Q: What customer data (e.g., network models, asset data, consumption data) do you collect, store, or process?

None, in the standard configuration. Because simulations run locally and files are saved locally, hydraulic models, infrastructure data, and any customer information contained in them never reach our infrastructure. Iterating Inc. is not a data processor for your infrastructure or customer data on self-service plans — we have no technical access to it.

Q: How is our data classified and segregated on your systems?

Not applicable — your model data does not exist on our systems.

Q: What are your data retention and deletion practices for our model data?

Not applicable — retention and deletion of model data are governed entirely by your own file storage practices, since the files live on your systems.

Q: Do you use our data to train AI or machine learning models?

No. We never use project files, network layouts, or customer data to train machine learning or AI models. For local projects, this is architecturally impossible: the data never reaches us.

Q: Which data residency regions apply to our model data?

Under self-service plans, your model data resides wherever you save it — your machines and your drives, in your jurisdiction. (For the limited-availability cloud programme, regional storage across the US, Europe, and Asia-Pacific is available, with data pinned to the selected region.)

4. Personal data and privacy

Q: What personal data do you process, and why?

We process a limited set of personal data related to the account itself, as described in our Privacy Policy (https://epanetjs.com/privacy-policy):

Account registration and login: email, first name, last name — managed via Clerk, our identity provider. Legal basis: performance of a contract.
Payments and subscriptions: name, email, and payment status — payment card data is handled entirely by Stripe; we never see or store card or bank details. Legal basis: performance of a contract.
Newsletter (optional): name, email, phone — managed via Kit, on the basis of express consent, with unsubscribe available at any time.
Support communications: contact details and whatever the user includes in their message.
Product analytics: browsing and in-app usage events via PostHog (see section 6).
Error and exception tracking: technical diagnostics via Sentry when the application encounters an error (see section 6).

Q: Are you GDPR compliant?

Our privacy programme is built to comply with GDPR and other applicable data protection regulations in the jurisdictions where we operate. Iterating Inc. is the data controller for account data. Users can exercise rights of access, rectification, erasure, restriction, objection, portability, and withdrawal of consent by contacting support@iterating.ca. Where subprocessors transfer data outside the EU, adequate transfer mechanisms such as EU Standard Contractual Clauses are in place.

Q: How long do you retain account data?

For as long as the account or subscription remains active and as required to meet legal obligations, after which it is deleted, unless the user requests erasure sooner. Full retention details per data category are in the Privacy Policy.

5. Subprocessors

Q: Which third-party subprocessors do you use, and for what?

Subprocessor	Purpose	Data involved
Clerk	Identity and authentication	Email, name, login credentials
Stripe	Payment processing	Payment details (held by Stripe, not by us)
PostHog	Product analytics	Usage and browsing events
Sentry	Error and exception tracking	Technical error diagnostics (error traces, browser/session context)
Kit	Newsletter delivery (opt-in)	Name, email, phone

No subprocessor receives hydraulic model data or customer infrastructure data, because that data never leaves the user’s machine.

6. Analytics, error tracking, and cookies

Q: What telemetry or analytics do you collect from the application?

We use PostHog to understand how the application is used (feature usage, navigation events) so we can prioritize improvements. Analytics events describe user actions within the application; they do not include the contents of model files. Analytics data is retained for no more than 18 months. Where non-essential cookies are used, user consent is requested; cookieless tracking options are used where possible to minimize privacy impact. See our Cookies Policy at https://epanetjs.com/cookies-policy.

Q: Do you collect error or crash reports?

Yes. We use Sentry for error and exception tracking. When the application encounters an error, a report containing technical diagnostics related to the user’s session (such as the error trace and browser context) is sent to help us identify and fix the problem. No model data is sent to Sentry: error reports do not include the contents of project files, network layouts, or simulation results.

7. Encryption

Q: Is data encrypted in transit?

Yes. All traffic between the user’s machine and epanet-js — application delivery, authentication, and any account-related communication — travels over HTTPS and is encrypted with TLS.

Q: Is data encrypted at rest?

Model data at rest is stored on your own systems under your own encryption policies (e.g., your corporate disk encryption), since it never resides on ours. For the limited-availability cloud programme, any model data stored on our servers is encrypted at rest with industry-standard AES-256.

8. Authentication and access control

Q: Does epanet-js support multi-factor authentication (MFA/2FA)?

Yes. Identity is managed via Clerk, which supports MFA using authenticator apps (Google Authenticator, Microsoft Authenticator, 1Password) and SMS verification codes. Workspace administrators on the Teams plan can enforce MFA across all members.

Q: Does epanet-js support single sign-on (SSO)?

SSO via SAML 2.0 and OIDC (Microsoft Entra ID, Okta, Ping Identity, Google Workspace) is available on Enterprise configurations. Self-service plans use email, Google, or Microsoft sign-in through Clerk.

Q: How is access to shared models controlled?

Under self-service plans, model access control is your own: whoever can access the file can open it, exactly like any other engineering project file, so your existing file permissions apply. (For cloud workspaces in the limited-availability programme, access is explicit and role-based — editor/viewer roles per member, with invitation and removal managed by workspace administrators.)

Q: Which of your staff can access our data?

None. Iterating Inc. staff have no technical pathway to your model or infrastructure data on self-service plans. Access to account data (email, name, subscription status) is limited to what is needed to operate the service and provide support.

9. Application security and development

Q: Is the source code available for review?

Yes. The epanet-js source code is public from day one under the Functional Source License (FSL) and becomes fully open source (MIT) two years after each release. Your security team can audit exactly how the application handles data at https://github.com/epanet-js/epanet-js. We consider this a stronger assurance than a closed-source attestation: you do not have to take our word for the data-flow claims in this document.

Q: What sandboxing applies to the application?

The application runs entirely inside the browser sandbox, subject to the browser’s security model — the same isolation and permission framework that governs all modern web applications. File access is limited to user-selected files via the File System Access API, and the simulation engine executes in WebAssembly within that sandbox.

Q: How are software updates delivered?

The application is delivered over HTTPS and updated centrally, so users always load the current version — there are no unpatched local installs to manage, and no installation or admin rights are required on user machines.

10. Compliance and certifications

Q: Do you hold SOC 2, ISO 27001, or similar certifications?

We do not currently hold these certifications. We would note that these frameworks primarily attest to controls around a vendor’s custody of customer data. Under self-service plans, Iterating Inc. never takes custody of your model or infrastructure data, so the vendor risk profile is closer to that of a software distribution channel than a data processor. Combined with public source code that your team can independently audit, this architecture substantially reduces the assurance gap those certifications are designed to close. For organizations whose procurement requires formal attestations, our Enterprise configurations are the appropriate path — contact sales@epanetjs.com.

Q: Does the product meet critical infrastructure or data residency mandates?

Under self-service plans, your infrastructure data never leaves your organization’s own machines and storage, which by construction satisfies data residency requirements: the data stays wherever your policies put it.

Q: Standard vendor questionnaires ask about your internal corporate controls — supplier security assessments, employee background checks, privileged account management, penetration test reports, incident-response exercises. How should we assess these sections?

These control families exist to measure the risk a vendor poses as a custodian of your data. On self-service plans, Iterating Inc. holds no model or infrastructure data, so a failure of our internal controls cannot expose it — the exposure those questions are probing does not exist in this architecture. We are a small, focused team and are transparent that we do not maintain the formal attestation artifacts (certified ISMS documentation, third-party penetration test reports, tabletop exercise records) that large enterprise vendors produce. What we offer instead is stronger for this deployment model: an architecture in which your data never reaches us, verifiable line by line in public source code, rather than a paperwork attestation you must take on trust. We suggest reviewers mark these sections “not applicable — vendor has no custody of organizational data” and note the architectural basis.

Q: What about the security of your suppliers and supply chain?

Our production suppliers are the subprocessors listed in section 5 — Clerk, Stripe, PostHog, Sentry, and Kit — each a major platform with its own mature security programme. Independent audit reports (e.g., SOC 2) for these providers are available directly from them. None of them ever receives your model or infrastructure data. The application code itself is public, so the software supply chain — dependencies included — is open to your inspection on GitHub.

11. Vulnerability management and incident response

Q: How do you handle vulnerability reports?

We take security reports seriously. Suspected vulnerabilities can be reported to support@epanetjs.com, and we work with reporters to investigate and resolve issues.

Q: What is the impact of a security incident on our data?

Because model and infrastructure data is never stored on our systems, a compromise of Iterating Inc.’s infrastructure cannot expose your network models or customer data on self-service plans. The exposure surface is limited to account data (email, name, subscription status) held by us and our subprocessors, each of whom maintains their own security programmes (Clerk, Stripe, PostHog, Sentry, Kit).

12. Availability and business continuity

Q: What happens to our work if epanet-js is unavailable, or if Iterating Inc. ceases operations?

Your project files are ordinary files on your own storage, and the application continues to run offline once loaded. Additionally, because the source code is public and converts to MIT after two years, the platform cannot become abandonware in the way closed-source tools can: the community, or your own organization, retains the legal and practical ability to run and maintain it. There is no vendor lock-in over your data — models remain accessible on your systems regardless of our status.

Q: Do users depend on your servers to run simulations?

No. Simulations execute locally in the user’s browser. Our servers are involved only in delivering the application and handling account functions.

13. Quick answers for common questionnaire items

Municipal and utility vendor questionnaires tend to ask a recurring set of questions. Short answers for self-service plans, ready to paste into your form:

Typical questionnaire item	Answer for epanet-js self-service plans
Is our organization’s data stored outside our networks?	No. Model and infrastructure data remains on your own machines and drives. The only data we hold is account data: email, name, subscription status.
Is our data shared with anyone outside your organization?	No. Model data never reaches the vendor, so it cannot be shared. Account data is processed only by the subprocessors listed in section 5.
If data is stored externally, where does it geographically reside?	Model data resides wherever your organization saves its files — your jurisdiction, your controls.
Data retention and disposal	Your own file-management policies govern model data in full. Account data retention is per the Privacy Policy.
Does the solution collect personal information?	Only registration details of your users who create accounts (email, name), plus product usage analytics and error diagnostics. Nothing from the contents of model files.
How is data protected at rest and in transit?	Model data at rest: your own storage controls apply. All traffic to the vendor (app delivery, authentication): HTTPS/TLS.
Single sign-on support	Self-service plans: sign-in via Google, Microsoft, or email through Clerk. SAML 2.0 / OIDC federation (incl. Microsoft Entra ID, Okta) on Enterprise.
Multi-factor authentication	Yes — authenticator apps and SMS via Clerk; workspace admins on Teams can enforce MFA org-wide.
Security certifications, SOC 2, penetration test reports	Not held by Iterating Inc. (see section 10). Independent audit reports for our subprocessors (Stripe, Clerk) are available from those vendors. Public source code available for direct audit.
Incident response	Vulnerability reports to support@epanetjs.com. A compromise of vendor infrastructure cannot expose your model data, as it is never stored there.
Can vendor access be revoked / accounts traced?	Your organization controls its own accounts; access to models is governed by your own file permissions, so your existing joiner/leaver processes apply unchanged.

14. Summary for reviewers

For the purposes of a standard vendor data-risk assessment of the self-service plans:

Data processed by vendor: account data only (email, name, subscription status, product usage analytics, error diagnostics).
Customer infrastructure/model data processed by vendor: none — architecturally excluded, verifiable in public source code.
Data residency of model data: customer-controlled (customer’s own machines and drives).
Encryption: TLS in transit for all vendor communication; at-rest encryption of model data governed by the customer’s own storage policies.
Authentication: Clerk-managed identity with MFA support; SSO on Enterprise.
Cloud functionality: opt-in per project, currently limited availability; can be disabled organization-wide for a hard architectural guarantee that no transmission pathway exists.
Appropriate assessment category: locally executed software delivered via browser, not a cloud data processor.

Questions not covered here: support@epanetjs.com · https://cal.com/epanet-js/