Security Document

What this document is about

Segmentic holds the behavioural data and contact details of a customer's end users and sends messages on that customer's behalf. A customer's security team usually wants to know three things before a contract is signed: where this data is, who can see it, and what happens if something goes wrong. This document answers those three questions and is public, because at that stage the team does not yet have an account to log into the panel with.

This is the English rendering. The Persian version is the authoritative one and governs if the two are ever read differently.

One rule governed the writing: describe only controls that exist, and wherever a control has not been built, say so on the spot. A whole article is given over to the list of what we do not have, because a buyer verifying this document finds a claim larger than reality faster than anything else.

This document is not a certification and does not take the place of an independent audit.

Article 1Where data is held

All data is stored and processed on infrastructure inside Iran, and backups do not leave the country either.

No binding law today compels an Iranian private company to do this. So it is a decision of ours rather than the discharge of a duty, and any move of the storage location is announced before it happens.

Article 2Encryption

**In transit.** Every public endpoint, meaning event intake, the API and the dashboard, answers only over TLS, and an unencrypted request is redirected to the secure version. Certificates are issued and renewed automatically.

**At rest.** Secrets whose disclosure from the database alone would be dangerous are encrypted with AES-GCM before they are written, and the key lives in the process environment rather than in the database. That means a stolen dump or a future SQL injection is not on its own enough. The items encrypted today are: the private DKIM key of a customer's sending domain, the credentials of sending gateways, the secrets of third-party connections, the secret of a single sign-on identity provider, and second-factor secrets both for the customer's users and for our own staff.

Clause 1-4 of the Executive Instruction on Improving the Protection of Users' Privacy, approved in 1402, states that personal data relating to identity "must be stored solely in encrypted form". That is not a best practice, it is a requirement, and we accept it as an obligation.

--- Note: field-level encryption of the identity items on an end-user profile, meaning the mobile number and the email address, is not yet fully implemented today. That work is in progress, and this sentence stays in this document until it is finished.

Article 3Tenant isolation

The model is shared infrastructure with a tenant identifier on every table, every key and every partition key. The data layer runs no query without that identifier, and a customer's access key opens onto that one tenant only. Processing quotas and the priority queue are per tenant as well, so that one customer's heavy query does not slow the rest.

This isolation is logical rather than physical. A dedicated deployment is possible but is not the default and is agreed separately in the contract.

Article 4Roles and the customer's own access control

There is no self-service sign-up. Every account is created by invitation only, so there is no path to an account being created without us.

Each customer account has separated roles: administrator, marketer, analyst, viewer and approver. API keys carry their own scopes, so a key meant for sending events cannot export an audience.

Three further controls belong to the customer and none of them is on by default: a second authentication factor, which an administrator may make mandatory for the whole account; single sign-on from the customer's own identity provider; and restricting logins to their network address ranges, up to fifty ranges. We do not switch any of them on for the customer, because switching them on from outside means the power to lock a customer out of their own account.

Article 5Our staff's access to customer data

Our internal panel is a separate surface, on a listener that is not routed from the internet. Its rules are not the same as the customer panel's and are stricter:

• **The second factor is mandatory** and the database structure itself enforces

it rather than a setting that can be turned off. The record of an active staff member without a confirmed second factor is not valid at all, so an account that declined second-factor enrolment cannot log in.

• **Reads are logged, not only writes.** The question this log has to answer is

"which member of staff opened this person's record", and a log of writes does not answer it.

• **Every change requires a written reason**, at least ten characters. That

floor does not stop a meaningless reason and is not meant to; it stops the empty string and the single full stop, which is what a mandatory field without a floor collects.

• **High-risk work requires the second factor again**, within the last ten

minutes: entering a customer account with write permission, deleting an account, creating or changing a staff role, and resetting somebody else's second factor. The threat this rule exists for is an open stolen laptop, not a stolen password.

• **Entering a customer account is read-only by default.** Any change made in

write mode is recorded in the customer's own audit log under a distinct label, so that a change the customer did not make can be told from one they did.

--- Note: high-risk work also requires a second person's approval, but while there is only one active staff member that is a lock with its key inside it. In that state the system accepts self-approval and records it under a distinct label, so that the period in which the company was run by one pair of eyes can be identified later. When a second account becomes active, the rule tightens by itself.

Article 6Audit logs

There are two separate logs: the customer's log, which holds changes inside their account with the user's name, the time, the network address and the kind of action, and which they can view and export themselves; and the staff log, which holds both reads and writes with a written reason. Both also record refused requests, because an unsuccessful attempt at access is exactly what an incident investigation looks for.

Logs and traffic data are kept for at least 180 days. Whether the statutory duty to retain traffic data applies to us exactly is not clear and we do not declare it as a settled obligation of ours; this figure is the most conservative reading. A customer's deletion request does not remove these logs either, and the detail is in the Data Retention and Deletion Policy, which is the document that governs.

Article 7Backup and restore

Automatic backups run every night at 03:20 Tehran time.

Keys are kept apart because a dump without the key is a set of columns with no way back. A backup is encrypted with the public key and the private half is deliberately not on the server: whoever has taken the server has the backup files too, and encryption whose key sits beside it is not encryption.

Every night an automatic check measures the age of the latest copy, that it was encrypted, and that it reached its external destination. The most important alarm is on the case where the backup did not run at all, because that case writes no metric, and an alarm that only fires on "too old" stays silent in exactly the worst case.

Article 8Secrets and keys

The system encryption key and the web push sending keys are held in the process environment, not in the database and not in the code repository. If the key is not set, the system refuses to create a sending domain rather than writing the secret to disk in the clear. This is not a key management system and we do not claim it is: there is one key per deployment, and rotating it means re-encrypting rows.

Article 9Reporting a vulnerability

If you find a vulnerability, write to support@segmentic.net with the word "security" in the subject. We acknowledge receipt within two working days at the latest and report status periodically until it is fixed.

If the reporter goes no further than is necessary to demonstrate the finding, takes no data, does not disrupt the service and does not disclose before the fix, we will not pursue legal action, and we confirm that in writing.

--- Note: we have no bug bounty programme and no payment is made for a report. Scanning, probing and penetration testing of the system without prior written permission is prohibited, and the article below that makes unauthorised access a criminal offence explains why this is not merely a contractual rule.

Article 10What we do not have

This article getting shorter is good news, and every time it does, it changes here. Today:

• We do not hold ISO 27001 or SOC 2 certification.
• We have no third-party penetration test report.
• We hold no AFTA certificate. That certificate is for providers of cyber

security services and contractors on government projects rather than for a marketing platform, but a banking or government customer may ask for it and we do not have it today.

• Field-level encryption of end-user identity items is not yet complete.
• Physical isolation of tenants is not the default.

Article 11Reaching another tenant's data is a criminal offence

Article 1 of the Computer Crimes Act of 1388, carried in consolidation into article 729 of the Islamic Penal Code, makes unauthorised access to computer data or systems "protected by security measures" an offence, punishable by ninety-one days to one year of imprisonment, a fine, or both. The offence is absolute: access alone is enough and no loss or gain need be shown.

The phrase "protected by security measures" has to be read carefully, because this whole document hangs on it. If we genuinely had no security controls, that criminal protection would not engage at all. Which is to say that the authentication, encryption, tenant isolation and access control described in the articles above are not only our commitment to the customer; they are what makes that article available to both of us. That is why keeping this document accurate is itself part of the control.

So attempting to reach another tenant's data, probing and scanning the system, and circumventing access restrictions are prohibited, trigger immediate termination of the contract, and are referred to the judicial authorities.

--- Note: article 2 of the same Act, carried into article 730 of the Islamic Penal Code, makes unauthorised interception of data in transit an offence punishable by six months to two years of imprisonment. Reciprocally, we do not inspect the content of a customer's data beyond what is necessary to provide the service.

Article 12Breach notification

If a security breach affecting customer data is established, we notify the contact person named in the contract within 72 hours. The clock starts at the moment of establishment rather than the moment of occurrence, and that difference is deliberate: before it is known, no deadline means anything.

The notification says at minimum what happened, when, which categories of data were involved, how many records if that is known, what we did and what the customer should do. If the picture is not yet complete we give an interim notification and complete it afterwards, because silence until everything is clear is the worst option.

This deadline comes from no statute. Iranian law today imposes no breach notification duty, neither to the customer nor to a supervisory authority, and we have set this figure ourselves.

--- Note: notifying end users is the customer's to do, because the relationship with the end user is theirs and the wording of that notification should be theirs too. We give them the data and the analysis that notification needs.

Article 13Changes to this document

Changes to this document are announced at least 60 days before they take effect. A change that weakens a control is not edited in silently, and the previous version stays available so a customer can put the two side by side.

Contact

Security questions and vulnerability reports: support@segmentic.net

Requests concerning personal data: privacy@segmentic.net

Kargostaran Nasl Javan Bakhtar https://segmentic.net