First column
Security
Protecting the account and the document from unauthorised access, and from silent changes after signing.
- Every connection encrypted with TLS 1.3
- Authenticating the signer with OTP
- SHA-256 fingerprint of the file
Wthaiq is a documentation and evidence authority for transactions and contracts. This page explains how we protect your account and your documents, how we handle your data, what we do when a security incident happens, and what we never do. At the end of it there is a practical method for checking everything we say for yourself, without taking our word for it.
Trust in a contracts platform is not a single item. We build it on four separate pillars, each with its own controls, and each pillar has a detailed section on this page.
Protecting the account and the document from unauthorised access, and from silent changes after signing.
Your data and your documents are yours. We use them to run the service you asked for, and for nothing else.
A contract you cannot reach when you need it might as well not exist. Continuity is part of security.
We explain clearly what we do, we tell you when something happens that warrants telling, and we give you the tools to check for yourself.
Most of the real risk in contract systems does not come from broken encryption — it comes from a stolen account, a session left open or a shared device. So we handle account protection on three levels: authentication, sessions and devices.
We store your password in a hashed form that cannot be reversed. Nobody can read it or extract it, not even our own team. That is why we will never ask you for it by email, by phone or in chat. Any message that asks for it is a phishing attempt, so delete it and tell us.
At the moment of signing we send a one-time verification code to the signer's own channel, their email or their phone number. The signature does not complete until the code is entered correctly. This separates “who opened the link” from “who owns the channel”, which makes impersonating the signer far harder than passing a PDF around by email.
OTP · time-limited · single useEach party to the contract gets a link of their own, and that link grants no rights over the rest of your documents or over your account. In practice, that means forwarding the link to a third person does not make them an approved signer — because the authentication step stays tied to the original signer's channel.
We record the important actions in the audit trail attached to the document: sending a document for signature, and completing a signature. And when there is a sign-in from a new device, an alert reaches your email carrying a link to revoke that device. Transparency is the fastest alarm system: if you see an event you did not carry out, you catch it early.
The session is tied to the device you signed in from, and you can revoke any device you do not recognise from the alert link sent to your email. If you use a shared device, sign out yourself when you finish.
“Sign out” ends your session on the server, not just in the browser. Get into the habit of using it on any device you do not own outright, and revoke the device from the alert link if you forget.
Every page and every request goes through a channel encrypted with TLS 1.3, signing pages included. There is no “insecure” path we let slide because it is internal.
Protecting a document means three different things. The first is that nobody unauthorised can read it. The second is that one organisation's data never mixes with another organisation's data. The third is that each person holds the narrowest permission their work requires. We explain each one separately.
Uploading the document, viewing it, signing it and downloading it — all of it goes through TLS 1.3. Anyone intercepting network traffic between you and the platform sees encrypted data, not contract content.
In transitWhen signing completes, our server builds a record and signs it with an asymmetric digital signature. Any party can verify it with the public key published at the end of this page, without coming back to us.
Independent proofA digital fingerprint for every completed document SHA-256. Change a single letter or comma in the file and the fingerprint changes completely — tampering becomes visible, not hidden.
File integrityYour documents are tied to your account, and no other account can view or search them. There is no “public list” of contracts on the platform, and no document is made available to any party you have not added to the signing cycle.
A signer sees only the document they have been asked to sign and their role in it — not the rest of your documents or your folders. A law firm sending a contract to one client does not expose its other clients' files in the process.
The content of your contracts is not material for our team to browse. Access to content is restricted to an operational need or an explicit support request from you, and it stays documented. The detail is in the What we do not do.
Our principle on permissions is “the narrowest permission that does the job”. And the necessary complement to any permission is documentation: every event on the document is written into an audit trail that cannot be edited once written, and is made available to you along with the document.
| Validity | Document owner | The listed signer | Whoever holds the verification number |
|---|---|---|---|
| View the document content | Yes | Yes — the document to be signed | No |
| Signature | if they are a party | Yes — after OTP authentication | No |
| Managing the parties and the cycle | Yes | No | No |
| Download a copy and the log | Yes | Yes — to their own copy | No |
| Checking the document's status and its fingerprint | Yes | Yes | Yes — status confirmation only, via /verify |
With contracts it is not enough for data to be protected; it has to be Present and available years later, and precisely when it matters: at a review, in a dispute, during a financial audit. So we separate three ideas that many people run together.
Our stated target is availability of 99.9% as a target level for running the platform. And we make sure the signing and verification path is the last thing affected by any maintenance work.
We take backups of the database and upload them to storage outside the server. And we check the integrity of every file the moment it is created, because a truncated backup is worse than no backup at all. This covers hardware failure, human error and accidental deletion. And we treat a backup as sensitive data, exactly like the original.
A backup you have never tested restoring is not a backup, it is a wish. So we built a tool that checks the backup in practice: it imports it into a separate temporary database and compares tables and rows against the original — rather than a plan written down in a file.
The strongest guarantee we can give you is that you are never locked into the platform. A completed document is a file in your hands, with its event log and its fingerprint, usable and enforceable well away from your account.
Keep a copy of every completed contract in your own archive together with its verification number. A small administrative habit that means you never have to depend on anyone else when you need it.
Hash SHA-256 It lets any party confirm later that the file in their hands is the very one that was signed, letter for letter.
Page Verifying the validity of a document It works for anyone holding the verification number, so the other party can check for themselves.
No platform in the world can promise that something will never happen; anyone who says otherwise is selling you reassurance, not security. What can be promised is Predefined behaviour when it happens. This is our process, and we publish it before we need it, not after.
The first priority is stopping the impact: cutting off the exploited path, revoking suspect sessions or keys, and preventing the scope from widening. Containment comes before analysis, because every minute of delay means a wider impact.
We establish exactly what happened, who was affected, which data was touched, and whether there was actual access or merely an unexploited gap. We do not report half-confirmed information, and we do not delay while looking for a perfect account.
We believe that hiding things doubles the harm. So if an incident affects your data or your documents, our approach is to tell you in plain language: what happened, which data was involved, and what we are asking you to do — not a vague statement weeks later.
Closing the root cause, not just the visible symptom, then verifying that the fix works. We also review whether the same pattern is possible elsewhere in the system.
A post-incident review produces lessons you can act on: what delayed detection? Which alert should have fired? An incident that changes nothing in the system will happen again.
Defining things by what they are not is clearer than general promises. These are practices we do not engage in, and stating them here is a written commitment you can hold us to.
Your data is not the product. We do not sell user data or signing party data, and we do not make it available to advertisers. We use data to run the service you asked for and to communicate about it.
The content of your documents is not there for our team to read or review. The only exception is when you ask for support with a specific document, in which case it is accessed only as far as is needed to solve your problem, and that access is logged. There is no “random review” of contracts and no browsing out of curiosity.
Your documents are not display material and not a business model. We do not republish your contract, use it as an example, or build marketing content on it. The document belongs to your business.
Nobody on our team will ever ask you for your password or your verification code, on any channel and for any reason. Anyone who does is not from us. Report any such attempt to us immediately at The contact page.
A document is not changed after completion without leaving a trace. The fingerprint SHA-256 and the audit trail exist precisely to make any change visible, rather than something to be believed or denied in words.
You will not find an international certification badge on this page, nor a reference to an external audit, nor a third-party rating. We state what we apply technically, and leave the checking to you. A polished claim is easier than the work — and more dangerous.
A page the provider writes about themselves is not enough. These are practical steps you can carry out today to verify a large part of what we have said above — with your own tools, with no intermediary, and without asking us.
Click the padlock in the address bar and inspect the connection and certificate details. It is the browser — not us — telling you the channel is encrypted and the certificate is valid and issued to our domain. That is a test you can repeat any time.
Take a verification number from a contract of yours and enter it in The verification page, and note what it shows: the status, the digital fingerprint and the event log. Try a wrong number too — the page should tell you the document does not exist, not invent a result.
Download your copy of a completed contract, and compute the fingerprint SHA-256 for it using a tool on your own device, then compare it with the fingerprint shown on the platform. A match is mathematical proof that the file has not been touched — not a promise from us. A difference means the file in your hands is not the signed copy.
Look over the event log of a contract you already have: sending, opening, OTP authentication, completion. Then ask yourself: does this log tell the story of the contract to a third party who witnessed none of it? If the answer is yes, it is a log that works as evidence rather than decoration in the interface.
Do not rely on our summary alone. Read the Compliance to learn the Egyptian legal framework we work under and your rights, then read the legal text itself or consult your lawyer. Any claim we cannot substantiate is one you will not find written here.
The best audit is a trial run: create one document, send it to yourself or a colleague, and walk the whole cycle end to end. Step-by-step details of the journey are in How it works, and what the certificate contains in E-signature certificate.
Enter the verification number on the document or in the completion message.
Every contract that completes signing on Wthaiq is sealed with a record. Our server builds this record and signs it with an asymmetric digital signature using Ed25519. Any party — your opponent in a dispute, your lawyer, or a court — can verify that signature with the public key below alone. The record also carries a certified timestamp from an independent authority, proving when the signing took place.
56d340a206e3a0b0
lnmELd8GoAwDTMkDI83ws72+icIYLfX5UhedVYq6rts=
The contract owner can download the “evidence file” (JSON) from the verification page; it contains the original record, the signature and the timestamp. Any party can verify the signature over the bytes of the record with this key, using any standard Ed25519 tool.
If you are a security researcher, or a user who has noticed suspicious behaviour, we treat your report as a service to us and to our users, not as a threat. We ask only that the report be responsible: that you notify us first and allow us a reasonable period to address the issue before any public disclosure, and that you go no further than demonstrating that the issue exists.
Send the details via The contact page and state in the subject line that it is a security report, so it is prioritised in triage.
The link or the page, the steps in order, what you expected and what happened, and the time of the attempt. A clear report cuts the fix time to a fraction.
Do not widen the exploit, do not download data, do not change anything and do not expose other people's accounts. Demonstrating that the vulnerability exists is entirely enough.
We read every report we receive, and we treat anything that proves a genuine risk with the seriousness and priority it deserves. Contact us via The contact page and attach the steps that show the problem.
These are the questions risk departments and IT teams usually ask before bringing a contracts platform into service. We answer them with what we actually apply, and within the limits of what we can substantiate.
Trust becomes clear from reading across pages, not from one page alone. These are the topics most closely related to what you have just read.
What the completion certificate contains in detail, how to read it, and its value as proof when you need it.
Read the detailsThe Egyptian legal framework for electronic signatures, your rights over your data, and retention periods.
Read the detailsConfirm the status, the fingerprint and the event log of any document by verification number, with no sign-in.
Try it nowThe contract's journey inside the platform from creation to completion, and where the security steps sit within it.
Read the detailsReal-world cases for shipping companies, law firms, HR departments and payments.
Read the detailsCommon questions about signing, legal standing and everyday use, answered directly.
Read the detailsDo not settle for reading about us. Create one document, walk it through the full cycle, then check the result for yourself.
This page explains the platform's policies and its technical and operational practices; it is not legal advice and it is not an audit report issued by an external body.