Security

Card data

This is the part most restaurant owners care about, so it goes first.

Our API refuses a payment request that contains raw card data rather than processing it, so a bug or a modified client cannot cause a card number to be stored by mistake. A token cannot be reversed into a card number, and a token stolen from us would not be usable to charge a card elsewhere.

Card processing is handled by NMI (Network Merchants, LLC), and by Square where a merchant uses it, under their own PCI DSS compliance programs.

We say that card data is handled by a PCI DSS compliant gateway and does not touch our systems. We do not describe Cobblestone POS itself as "PCI compliant", because we have not completed an independent PCI DSS validation of the Platform. Keeping card data out of our systems is the point — it means there is nothing on our side to validate.

Isolation between merchants

Each merchant's data is stored under its own tenant scope and queried separately. Authorization is enforced on the server from a verified identity token and the tenant claim it carries — never from a value the client sends — so one merchant cannot read or write another's records by changing a request.

Encryption

• All connections to the Platform use TLS. Card data entered in a gateway card field goes directly from the browser to the gateway over its own TLS connection.
• Data at rest is encrypted by our cloud provider, including the database, file storage and backups.
• Passwords and register PINs are stored as salted hashes. We cannot read them, and neither can we recover one for you — we can only reset it.

Access control

• Authentication runs through a managed identity provider rather than a password system we wrote ourselves.
• Permissions are role-based. A cashier, a manager and an owner see different things, and sensitive actions — voids, refunds, discounts, price overrides, payroll and settings — can be restricted to a role.
• Register PINs are per-employee, so an action on a shared tablet is attributable to a person.
• Our own personnel access is least-privilege and limited to what support and operations require.
• Secrets and API keys live in managed secret storage, not in source code and not in a committed configuration file.

Monitoring and audit trail

• Significant actions are written to an audit log — voids, refunds, discounts, price overrides, cash drawer events, permission changes and settings changes — with who did it and when.
• Application and error logs are collected centrally and monitored for failure patterns.
• Our API applies rate limiting, request validation and standard HTTP security headers.
• Unusual payment activity surfaces in reports, and a reconciliation tool flags a refund made outside the Platform.

Availability and backups

• The Platform runs on Google Cloud infrastructure across managed, redundant services.
• The database is backed up automatically, with point-in-time recovery available from the provider.
• The register continues to operate through a network outage for most functions and queues what it cannot send, syncing when the connection returns.
• You can export your own data — sales, customers, menu, invoices, reports — at any time from the admin panel. Keeping your own copy is good practice, and we encourage it.

Vendors

Every vendor that handles merchant or customer data is listed by name, purpose and location in our Data Processing Terms, along with our commitment to give notice before that list changes. Each is engaged under a contract with data protection terms, and each receives only the data its function requires.

Incident response

If we become aware of a personal data breach affecting a merchant's customer data, we notify the affected merchants without undue delay and no later than 72 hours after becoming aware, with what happened, who is affected, what the likely consequences are and what we are doing about it. We keep merchants updated as we learn more, and help them meet their own notification obligations. We notify regulators and individuals where the law requires it.

What we do not claim

A security page that only lists strengths is not much use for making a decision, so here is the other side.

• No SOC 2 report and no equivalent third-party audit today. If your procurement process needs one, tell us where you are in the process and we will be straight with you about timing.
• No independent PCI DSS validation of the Platform itself, for the reason explained above.
• No penetration test report from an external firm to share.
• No formal uptime SLA on the free Platform. We work to keep it up; we do not contractually guarantee a percentage.
• No bug bounty program, though we do want reports and will credit a reporter who asks to be credited.

We would rather lose a deal over this list than win one by implying a certification we do not hold.

Your part

Most real-world compromises of a restaurant system start at the counter, not in the cloud. The things that actually matter:

• Give each employee their own login and PIN. Never share one.
• Remove access the same day someone leaves.
• Use the lowest role that lets a person do their job, and keep owner access to owners.
• Use a strong, unique password for your admin account and do not reuse it elsewhere.
• Never write a card number down, and never ask a customer to text or email one. If someone asks you to key a card into a form that is not the register or the gateway's own fields, stop.
• Keep the register app updated — updates include security fixes.
• Treat an unexpected call or email asking you to change bank details or read out a code as fraud until you have confirmed it through a number you already had.

Reporting a vulnerability

If you believe you have found a security vulnerability, email hello@cobblestonepos.com with the subject line Security. Include enough detail to reproduce it.

We will acknowledge a report within 3 business days, keep you informed while we investigate, and will not pursue legal action against anyone who reports a vulnerability in good faith, gives us reasonable time to fix it, and does not access, modify or delete other people's data in the process. Please do not run automated scans or load tests against production, and do not test against a live restaurant's register — ask us and we will arrange a safe way to test.