Restaurant management built around the kitchen pass Seven modules, one order record, one login
Dearrasa

Home/Security

Stated as it is

What we do today, what we are building, and what we do not claim.

Security pages in this industry tend to list badges. This one lists practices, separates current status from roadmap, and names the certifications Dearrasa does not hold yet, because you are trusting us with your takings and your guests.

Payments

The safest way to handle card data is to never hold it.

Dearrasa is deliberately out of the card data path. That is a design decision, and it is the single most useful thing we can tell you about payment security.

Card payments

Processed by your provider, not by us

Card transactions are captured on the payment provider's own certified terminal or gateway. Dearrasa receives the result, the amount, the tender type and a transaction reference so the bill can be settled and reconciled. Full card numbers, expiry dates and verification codes are never transmitted to, processed by or stored in Dearrasa.

Scope

What this means for your PCI obligations

Because Dearrasa never touches cardholder data, using it does not extend your cardholder data environment into our software. Your obligations continue to sit with your acquirer and your terminal provider, and we will provide a written description of the integration for your auditor on request. We do not claim that using Dearrasa makes your restaurant PCI compliant, because that is not something any restaurant management vendor can honestly claim on your behalf.

UPI and wallets

Reference recorded, credentials never

UPI and wallet settlements are recorded with their reference and amount so the tender reconciles at shift close. No customer payment credential is stored.

Cash

The oldest risk gets the same treatment

Drawer openings, voids after a ticket is fired, discounts above threshold and shift variances are recorded with a user, a terminal and a time. Cash control is a security feature, and in a restaurant it is often the one that matters most.

Access

Role based access, scoped by outlet as well as by function.

Most restaurant data leaks are not attacks. They are a shared manager login and a curious ex employee.

Practice

Least privilege by default

A station screen cannot see prices. A cashier cannot see margin. An outlet manager cannot see another outlet. Access is granted by role, not by seniority.

Practice

Individual logins, unlimited

Staff logins are not charged for, precisely so nobody has a financial reason to share one. Every action carries the person who took it.

Practice

Immediate revocation

A departing staff member is deactivated in one action, on every device and every outlet, and their historical actions remain attributed to them.

Practice

Approval thresholds

Discounts, comps, voids after fire, price overrides and stock adjustments above limits you set require a higher role and a recorded reason.

Practice

Audit trail that cannot be edited

Sensitive actions are append only records. They can be read and exported, and they cannot be altered or deleted from within the product by anyone, including us.

Practice

Owner visibility over admins

Permission changes are themselves logged and surfaced to the account owner, so quietly granting oneself more access is not a quiet action.

Data

Where it lives, how it travels, how long it stays.

In transit and at rest

  • All traffic between your devices and Dearrasa runs over TLS. Local device to printer traffic stays on your own network.
  • Data at rest is encrypted using the managed encryption provided by our cloud infrastructure, with keys managed by the platform key service rather than held in application code.
  • Each restaurant group's data is logically separated, and no query path exists that returns another tenant's records.
  • Credentials are stored as salted hashes. Nobody at Dearrasa can read your password, and support will never ask for it.

Backups and retention

  • Automated daily backups with point in time recovery, retained on a rolling window, held in the same country as the primary data.
  • Restores are tested on a schedule. A backup that has never been restored is a hope, not a backup.
  • Sales, tax and invoice records are retained for the statutory period applicable in India, because you are legally required to be able to produce them.
  • Guest personal data is retained only while it serves the purpose it was collected for, and is removed on request as described in the Privacy Policy.
  • On account closure, you can export everything, and your data is deleted after the retention window we state in the terms.
Resilience

Service continues when the connection does not.

Offline

Local first at the counter and the pass

The current shift is held on the device. Orders, timers, modifications, printing and cash settlement all continue with no connection.

Sync

Ordered reconciliation with original times

Local actions carry a device identity and timestamp and post in sequence when the line returns, so reports for the day stay accurate.

Limits

What offline cannot do

Aggregator intake, card and UPI authorisation, cross outlet views and fresh forecasts require connectivity. We state this rather than implying total independence.

No overclaiming

Certifications, stated as current status.

The following is where Dearrasa genuinely stands. Roadmap items are labelled as roadmap, and we will not describe an intention as an achievement.

Current

Out of card data scope

Dearrasa does not store, process or transmit cardholder data. This is an architectural fact today, and we will describe the integration in writing for your auditor.

Current

Practices in place, not yet independently certified

Encryption in transit and at rest, role based access control, tenant separation, audit logging, tested backups, and access to production restricted to a small number of named engineers with individual accounts. These are implemented and in use.

Roadmap

Independent audit

A formal third party information security audit is planned. Dearrasa does not currently hold ISO 27001 or a SOC 2 report, and we will not imply otherwise. When an audit is completed, this page will state its scope and date rather than displaying a logo.

Roadmap

Published incident commitments

Our current commitment is to notify affected customers directly and promptly, with what we know, what we do not yet know and what we are doing. Formal published response time commitments will be added to the terms as the company grows, and will be stated as commitments only when we can meet them.

Always

Report something to us

If you believe you have found a vulnerability in Dearrasa, write to us through the contact page and mark it as a security report. We will acknowledge it, investigate, and tell you what we found. Good faith research will never be met with a legal threat.

Next service

Send us your security questionnaire.

If your group or your auditor needs a specific document, ask. We will answer what we can evidence and tell you plainly where the answer is no.