CEDX Systems · Legal

Security

Security page written for a vendor review. Removes the unverified password-storage and tenant-scoping claims, corrects the breach trigger to "become aware", adds the free-text card-number caveat, routes the subprocessor list to DPA Annex 3, splits the DPO question from the Article 27 question, and c

Last updated: 8 August 2026 · Version 1.0

This page is written for the person doing a security review. It says what we do, how we do it, and — in its own section near the bottom — what we have not built yet. Every sentence here is meant to be true on the day it is published and to stay true. If you find one that is not, tell us and we will correct it.

In short

• We don't hold a SOC 2 report or an ISO 27001 certificate, and we don't commission third-party penetration tests. We won't imply otherwise to win a deal.
• Card numbers do not reach our systems through the payment path. Payments are handled by JPMorgan Chase Bank, N.A., through Chase Payment Solutions.
• Customer data lives in Postgres. Tenants are separated logically — one database, records scoped to the customer they belong to — not by running separate infrastructure per customer.
• Our marketing site loads no analytics, no tag manager, no session recorder, no advertising pixel, no A/B tool and no chat widget. There is nothing on it watching you.
• If we become aware of a security incident affecting your data, we tell you in writing, with what we know — immediately following discovery where the data is yours, and in no case later than thirty days after we discover it, which is the outside limit New York's General Business Law § 899-aa sets.
• Found a vulnerability? Write to security@cedxsystems.com, or CEDX Corporation, 307 W 38th St, 16th Floor, New York, NY 10018. Good-faith research that follows the policy at the bottom of this page is authorised, and we will not take legal action over it.

Who this page is about

This page describes the systems operated by CEDX Corporation, a New York corporation doing business as CEDX Systems ("CEDX Corporation", "we", "us"). It covers cedxsystems.com and the CEDX platform — CEDX CRM, CEDX Desk, CEDX Invoicing and the other apps that share the platform's identity, directory, workflow, events, entitlements, files and AI gateway services.

It does not cover CEDX (the 501(c)(3) research institution at cedx.org). That is a separate organisation with separate books, separate systems and separate people. Nothing on this page is a statement about the CEDX 501(c)(3), and nothing it does is a statement about us. If a reviewer has been given a document that treats the two as one company, it is wrong.

This page describes security practices. It is not an availability promise — those live in our Service Level Agreement. It is not our contract for handling your data — that is the Data Processing Addendum, which is pre-signed and available to read before you buy.

Where your data is

Customer data is stored and processed by Customer data is hosted on dedicated virtual infrastructure provided by Hostinger International Limited, in a data centre in Vilnius, Lithuania. The servers run in UTC.. No. All customer data is held in a single region and we do not offer a choice of processing location today..

Our primary data store is Postgres. The authoritative list of every third party that can touch customer data is Annex 3 of our Data Processing Addendum, which we keep current and which you should read alongside this page. It includes the network provider that sits in front of the site and the product and terminates TLS for every request. Customer data is held in SQLite databases inside the application containers, not in Postgres, and Supabase is not in use for the Services covered by this agreement..

Support, error monitoring and model inference may involve systems outside the primary region. Where they do, Annex 3 names them and says where they run.

Encryption

In transit. All traffic to cedxsystems.com and to the CEDX platform is served over HTTPS. Plain HTTP requests are redirected. Our servers accept TLS 1.2. TLS 1.0 and 1.1 are refused; TLS 1.2 and TLS 1.3 are accepted. Verified against the live configuration on 8 August 2026. and above. We do not publish cipher-suite claims we have not verified against the running configuration.

At rest. Customer data is stored on the server's own filesystem. There is no full-disk or volume-level encryption layer in place today, and backups are compressed rather than encrypted. Data is encrypted in transit.. If the honest answer is provider-level disk encryption rather than something we manage ourselves, this page will say exactly that rather than the more impressive version.

Who can reach production

Production access is limited to the people who need it to keep the service running. Two registered keys hold production access, both operating as system administrators..

• Production access is by SSH to a single host, restricted to two registered public keys. Key-based authentication is in use and access is limited to the root account..
• Production access is granted by adding a named key and removed by deleting it. Access is reviewed whenever someone joins or leaves, and shared credentials are rotated at the same time.. We would rather describe this once we can show you a record of it than assert a process from intent — and if the honest answer is that some secrets are shared and rotation has been ad hoc, this page will say so.

How our people handle your data

We do not read customer data as part of routine work. Our staff open a customer's records in three situations: when you ask us to, in order to resolve a support request; when we are investigating a fault or a security event that we cannot diagnose any other way; and where the law requires it.

Everyone with access to production is bound by a written confidentiality obligation that survives their engagement Everyone with access to Customer Personal Data is bound by written confidentiality obligations.. Deliberate misuse of customer data is a dismissal matter, and we will refer it for prosecution where the conduct warrants it.

We do not run formal background checks on staff or contractors with production access today..

Tenant isolation

The CEDX platform is multi-tenant, and the platform deliberately holds one shared customer record that the individual apps read from. That design is what makes CRM, Desk and Invoicing agree with each other about who a customer is. It also means isolation is a data-layer question, so here is the honest description of it.

Isolation is logical, not physical. Your records sit in the same Postgres database as other customers' records and are separated by the customer account they belong to. We do not run a separate database or a separate instance per customer. Tenant separation is enforced in the application layer, which scopes every query to the signed-in account.. We describe the mechanism here only once we have read it in the code rather than inferred it from the design.

Cross-tenant access is the failure mode we care most about, and it is the class of bug we most want reported. See the disclosure policy below.

Our security programme, and what New York requires of it

New York's SHIELD Act — General Business Law § 899-bb — applies to any business that owns or licenses computerised data containing the private information of a New York resident, whether or not it otherwise does business in New York. There is no revenue threshold and no minimum number of affected people. It reaches us because New York residents' information passes through our systems, not because we are incorporated in New York; incorporating somewhere else would not have changed it. What it requires is a data security programme with reasonable administrative, technical and physical safeguards. Nobody issues a certificate for it. What follows is the programme itself, element by element, in the statute's own order, with the gaps left visible.

Administrative. One named person coordinates the security programme: Mukesh Thakur, Chief Executive Officer. We identify the internal and external risks we can reasonably foresee and write them down; we assess whether the safeguards described on this page are sufficient against those risks; and we revise the programme when the business changes — a new subprocessor, a new app in the catalogue, a new category of data. Everyone with access to production is bound by written confidentiality obligations and is expected to handle customer data the way this page describes. We do not run a formal security-awareness training programme today. Production access is limited to two administrators.. We select subprocessors on their ability to maintain appropriate safeguards and we require those safeguards by contract: the subprocessors are named in Annex 3 of our Data Processing Addendum and the contractual standard they are held to is Annex 2.

Technical. We assess risk in network and software design, and in how information is processed, transmitted and stored, as part of how we build rather than as a separate exercise with a report at the end. Traffic is encrypted in transit as described above; encryption at rest is Customer data is stored on the server's own filesystem. There is no full-disk or volume-level encryption layer in place today, and backups are compressed rather than encrypted. Data is encrypted in transit.. We monitor for attacks and system failures and respond to them under the incident process in the next section. On the statute's fourth technical element — regularly testing and monitoring the effectiveness of key controls — we will not overstate what we do: we have not commissioned a third-party penetration test, and nothing in this programme should be read as one. Operating-system packages are patched automatically. Backups are integrity-checked weekly and their freshness is checked every six hours, with an alert raised on failure. We do not run automated application-dependency scanning or continuous log review today..

Physical. We run no data centre and no office server holding customer data. The physical safeguards over the machines are the hosting provider's, named in Annex 3, and the provider's safeguards are part of why we selected it. What is physical and ours is the devices our people work from and the disposal of data we no longer need. We delete private information within a reasonable time after the business purpose for holding it has ended, and we erase media so that the information cannot be read or reconstructed. The periods are set out in Account and profile records for the life of the account and 60 days after; billing and tax records for seven years; support correspondence for two years; security and server logs for 12 months; security incident records for six years; prospect records for 24 months; job applicant records for 12 months. and in the retention section of our Privacy Policy.

The Act scales this to the business. A small business — fewer than fifty employees, or less than $3 million in gross annual revenue in each of the last three fiscal years, or less than $5 million in year-end total assets — is required to keep safeguards appropriate to its size, to the nature and scope of its activities, and to the sensitivity of the data it holds. CEDX Corporation meets the § 899-bb(1)(c) small-business definition on two limbs: fewer than fifty employees (18), and under $3,000,000 in gross annual revenue.. We would rather tell you which standard we are actually held to than let you assume a larger one. We also do not claim the Act's alternative route for a "compliant regulated entity": we are not subject to Gramm-Leach-Bliley, to HIPAA, or to the New York Department of Financial Services' Part 500, so we meet § 899-bb on its own terms and not by borrowing someone else's regulator.

Accounts and sign-in

Accounts are per person, and we ask you not to share logins between people — shared accounts destroy the audit trail that makes an investigation possible.

Until that line is filled in from the code, we make no claim here about how credentials are stored.

Two-factor authentication using an authenticator app is available on customer accounts..

Your administrators control who in your organisation has an account and what each account can reach, through the platform's entitlements service.

Backups and restores

Backup integrity is verified weekly and the most recent verification passed. A full restore-to-a-clean-host drill has not been recorded..

A backup nobody has restored is a hypothesis, not a backup, so the restore-test date is the one we hold ourselves to. When it is filled in, it will state a real date and we will keep it current.

Dependencies and patching

The platform is built on open-source components, which means most of the vulnerabilities that will ever affect it will arrive through somebody else's code.

Operating-system packages are patched automatically through unattended-upgrades. Automated application-dependency scanning is not in place today.. We track advisories affecting the components we run, and we patch on a severity basis: anything being actively exploited or reachable from the public internet is treated as urgent and everything else is picked up in normal maintenance.

We don't commission recurring third-party penetration tests today. See "What we don't offer today".

The AI gateway

Several CEDX apps can send content to a language model through the platform's AI gateway. When that happens, the content you sent leaves our systems and reaches a model provider. That is worth knowing before you turn the features on.

The gateway is called only when a feature that uses it is invoked — it does not process your data in the background. The providers reachable through it, the regions they process in, and their retention and training terms are recorded in Annex 3 of our Data Processing Addendum: CEDX AI is CEDX Corporation's own assistant layer. It is not trained or fine-tuned on customer content. It calls third-party frontier models — Anthropic (Claude) and OpenAI — which process in the United States. Content you send to AI features reaches those providers, and what they may retain or train on is governed by their terms, which we name in Annex 3 rather than paraphrase..

We will not claim your data is never used for model training unless our provider's own terms say so in writing. CEDX Corporation does not train on it; that is a claim about us, and it is the only one we can make. We give at least 30 days' notice before adding or changing a model provider.

Payment data

We do not store, process or transmit full card numbers through the payment path. Payments run through JPMorgan Chase Bank, N.A. (Chase Payment Solutions). Card details are entered into Chase's own payment components and go to Chase directly. We do not store, process or transmit full card numbers, so we are not the party that holds the card-network attestation for that processing. Card details are entered into Chase's own components and go to Chase directly. What we hold is the non-sensitive remainder — the last four digits, the card brand, the expiry, and Chase's identifier for the payment method.

One caveat we would rather state than have you find: nothing stops a user typing a card number into a free-text field such as a note, a ticket or an invoice description. Our Acceptable Use Policy forbids it, and We do not run automated detection or redaction of card numbers typed into free-text fields. Do not put them there..

Chase acts as an independent controller for its own payment, fraud-prevention and anti-money-laundering purposes. Its own terms and privacy documents govern that part.

Security incidents and what we tell you

If we detect or are told about a possible incident, we work in this order: contain it, work out what happened and what it touched, fix it, then tell the people affected and write up what we changed.

If we become aware of an incident affecting your data, we notify you without undue delay. We treat ourselves as aware once we have a reasonable degree of certainty that a security incident has occurred and that personal data was compromised — not once the investigation has finished. We will tell you what we know at that point and the rest as we learn it: what happened, when, which of your data was involved as far as we can establish it, what we have done, and what — if anything — you need to do. We commit to a duty here rather than to a number of hours, because a number invented for a page is a number we would miss in exactly the week it mattered.

The deadline we are actually held to. We would rather quote New York's law than paraphrase it. Where private information we hold in our own right about a New York resident has been, or is reasonably believed to have been, accessed or acquired without valid authorisation, General Business Law § 899-aa requires notice "in the most expedient time possible and without unreasonable delay", and in no case later than thirty days after the breach has been discovered. The clock runs from discovery, not from the end of the investigation. Since December 2024 the only delay New York allows is one requested by law enforcement because notice would impede a criminal investigation — the law no longer lets a business hold notice back while it works out the scope of the breach or restores the system, and we do not claim that it does. Our notice will describe the categories of information involved and will carry our contact details together with the telephone numbers and websites of the state and federal agencies that publish guidance on breach response and identity theft, because § 899-aa(7) requires all three. Where New York residents are notified we also notify the New York Attorney General, the Department of State and the Division of State Police of the timing, content and distribution of the notice and the approximate number of people affected, with a copy of the template — and that filing never delays telling the people affected. If more than five thousand New York residents are notified at once, the consumer reporting agencies are told as well. We are not regulated by the New York Department of Financial Services, so the DFS notification in § 899-aa(8) does not reach us; if that ever changes, this page changes with it. We hold ourselves to the thirty-day outside limit for everyone, not only for New York residents, because running two clocks is how a company misses both.

Where the data is yours and we only hold it. For the data you put into CEDX, you are the owner and we are the business maintaining it. New York's rule for that case is stricter than the rule for our own data, and it is the one we work to: we notify you immediately following discovery of a breach, and in no case later than thirty days after discovery. What you then report, to whom, and on what timetable is your decision — the regulator's clock is yours, not ours, and our job is to give you what you need to run it. Our Data Processing Addendum says the same thing and is the version that binds us.

Business hours, US Eastern, Monday to Friday. Security reports are acknowledged within 2 business days..

Reporting a vulnerability

Send it to security@cedxsystems.com, or CEDX Corporation, 307 W 38th St, 16th Floor, New York, NY 10018. That inbox is monitored and is the right route for anything security-related — please do not use the general support channels for a vulnerability report. Yes. A security.txt is served at /.well-known/security.txt naming security@cedxsystems.com as the contact, with the security page as the published policy.. Once it is live, this sentence reads: we also publish the same address at /.well-known/security.txt.

Include enough for us to reproduce the issue: the URL or endpoint, the steps, what you expected and what happened, and any proof-of-concept you have. If you found it by accident, say so — accidents get the same safe harbour as deliberate research.

What we commit to. We acknowledge your report within Severity 1, service unavailable: acknowledged within 4 business hours. Severity 2, major feature degraded: within 1 business day. Severity 3, everything else: within 2 business days. Support runs in business hours US Eastern; we do not run a 24/7 staffed on-call and do not imply one., tell you whether we consider it a valid issue and roughly what we intend to do, and keep you informed until it is closed. We will credit you publicly if you want the credit and are happy for you to publish once the fix is out — talk to us about timing.

In scope. cedxsystems.com and the CEDX platform and its apps, including anything at a cedxsystems.com subdomain that we operate.

Out of scope. cedx.org and any system belonging to the CEDX 501(c)(3) — it is a different organisation, and a report about it sent to us goes nowhere useful. Also out of scope: third-party services we merely use, findings that consist only of a scanner's output with no demonstrated impact, missing security headers with no exploitable consequence, and reports about email configuration on domains we do not send from.

What you must not do. Do not run denial-of-service or load tests. Do not social-engineer our staff, our customers or our suppliers. Do not attempt physical access to anything. Do not send spam. Do not access, modify, delete or take data belonging to any account other than a test account you created yourself. If you come across another customer's data while testing, stop, do not save a copy, and tell us straight away — that report is more valuable to us than whatever you would have found by continuing.

Safe harbour. If you conduct security research in accordance with this policy, we consider that research to be:

• authorised in view of any applicable anti-hacking law, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy;
• exempt from any restriction in our Terms of Service or Acceptable Use Policy that would otherwise prohibit it, to the limited extent necessary to carry out the research;
• exempt from claims under anti-circumvention law, which we waive for this purpose; and
• lawful, useful to the security of the internet generally, and carried out in good faith.

This safe harbour is not discretionary. If a third party brings an action against you for research that complied with this policy, we will make it known that your activity was authorised by us. If you are unsure whether something you want to test falls inside the policy, ask us first and we will answer.

We do not currently run a paid bug bounty and we do not pay for reports. We say so plainly so that nobody spends a weekend on our platform expecting an invoice to be honoured. What we offer is a fast, honest response, credit where you want it, and coordinated timing on disclosure.

What we don't offer today

This is the section the rest of the page exists to make credible.

• No SOC 2 report. We have not completed a SOC 2 Type I or Type II audit, and we are not "SOC 2 aligned", "SOC 2 ready" or any other phrasing that means we do not have one. No SOC 2 readiness process has been engaged and no audit is scheduled.. If your procurement process requires a report, tell us early and we will tell you exactly where we stand rather than running you through a sales cycle that ends in a no.
• No ISO 27001 certificate. Same position, same honesty.
• No third-party penetration test. We have not commissioned one, so there is no report to share under NDA.
• No 24/7 staffed on-call rotation. We are a small team. Nobody is paged at three in the morning as a matter of routine, and we will not pretend otherwise.
• No named Data Protection Officer and no EU representative. We have not appointed a Data Protection Officer, because our processing is not the large-scale monitoring or special-category processing that Article 37 requires one for. We have not appointed an EU or UK representative under Article 27 either — No. CEDX Corporation offers the Services worldwide with the exception of the European Economic Area, the United Kingdom and Switzerland. We do not target, market to, or accept customers established in those territories, and the Services are not offered to data subjects there., which is what decides whether a representative is required. If the answer is yes, we appoint one and publish its details before we take that customer. Naming one on a web page does not create one, and neither does asserting that we do not need one.
• No bug bounty programme. Reports are welcome and unpaid, as set out above.

We would rather list these than have you find them on a call. A buyer who needs a SOC 2 report today will not buy from us today, and that is a fair outcome for both of us.

Security questionnaires

This page and our Data Processing Addendum, including its Annex 2 security measures and Annex 3 subprocessor list, answer most of what a standard vendor security review asks. If something you need is not covered, send it to security@cedxsystems.com, or CEDX Corporation, 307 W 38th St, 16th Floor, New York, NY 10018 and we will answer it within 10 business days.. We will answer the questions we can answer and write "no" against the ones we cannot, rather than leaving them blank.

Changes to this page

We review this page at least once a year and whenever something described on it changes. The "Last updated" date at the top always reflects the last substantive change, and from this version onwards we keep the previous versions available at stable URLs so you can see what a statement said on the day you relied on it.

If we make a change that materially weakens a commitment on this page, we email the administrator and billing contacts on your account at least 30 days before it takes effect. We do not treat continued use of the service as agreement to a change nobody was told about.

Change log