Information Management Policy

Quick Web Go

Last updated: 30 July 2026 Owner: Rahul Srivastav Review cycle: every 12 months, and after any security incident

1. Purpose and scope

This policy sets out how Quick Web Go handles information entrusted to it: our customers' business data, the personal data of their website visitors, and our own operational records.

It applies to everyone who touches that data — the founder, any employee, and any contractor or freelancer engaged for design, development or support.

2. Principles

Five principles decide every judgement call below.

1. The broker's data belongs to the broker. We hold it; we do not own it, and we do not monetise it.
2. Collect the minimum. Data we never collected cannot leak, be subpoenaed, or be misused.
3. Isolate by default. One customer, one deployment, one database.
4. Least privilege. Access is granted for a task and removed when the task ends.
5. Be honest when something breaks. Prompt disclosure beats a managed narrative, always.

3. Data classification

Rule of thumb: if it could identify a broker's client, it is C1 and it does not leave that broker's deployment.

4. Customer isolation — architectural, not procedural

The single most important control here is not a rule anyone has to remember.

Each customer's website is a separate deployment with its own database. There is no multi-tenant database, no shared lead table, no cross-customer analytics pipeline, no common queue.

Consequently:

• one customer's application cannot query another's data — the connection credentials do not permit it;
• a bug in listing filtering cannot expose another broker's leads, because they are not in the same database;
• a compromise of one site is contained to that site.

This is why the promise "we never share your data with other brokers" is dependable. It is not a policy that could be forgotten under deadline pressure; it is a property of how the product is deployed. Any future move to a shared database would invalidate this section and must be treated as a material change requiring customer notice.

5. Access control

• Production access is limited to one person: the founder, Rahul Srivastav. There is no operations team, and no other account holds production credentials. If that changes, this list is updated before the second person is granted access — not afterwards.
• No shared logins. Each person with access has their own credentials.
• Multi-factor authentication is enabled on every account that can reach customer data: hosting/cPanel, domain registrar, the bank account receiving UPI payments, email, code repository.
• Credentials are held encrypted, accessible only to the founder. They are never sent over WhatsApp, email or chat — if a credential has ever been sent that way, it is rotated.
• Contractors get access scoped to their task and time-boxed to it. Access is revoked the day the engagement ends, and revocation is verified, not assumed.
• Access to a customer's admin panel happens only with that customer's knowledge, for support they have asked for or maintenance we have told them about.

6. Encryption and transport security

• In transit: HTTPS/TLS on every site we host, with HTTP redirected to HTTPS. Enforced at the server, not left to the visitor.
• Security headers on every deployment: X-Content-Type-Options, X-Frame-Options, Referrer-Policy.
• Passwords are stored only as salted hashes (bcrypt). No plaintext, no reversible encryption, ever — including ours.
• Payment credentials never reach our systems. UPI transfers happen inside the payer's own UPI app, bank to bank. We record only the payer's UPI ID and the transaction reference, which are needed to match a payment and to refund it.
• At rest: customer data is protected by encryption where the hosting platform provides it, and by equivalent access controls where it does not — per-deployment database credentials, no shared logins, and multi-factor authentication on every account that can reach customer data (§5). Backups are encrypted (§8). Passwords are stored only as salted bcrypt hashes, and payment credentials never reach our systems at all, so the two most sensitive categories are not held in a recoverable form anywhere.

7. Sub-processors

We use as few third parties as the service allows. Each is listed in the Privacy Policy (§7), with what it handles and where.

Before engaging a new sub-processor that will touch C1 or C2 data we:

1. check it offers a documented security posture and a data-processing commitment;
2. confirm the data location, and disclose it if outside India;
3. update the Privacy Policy table;
4. notify customers before it begins processing their leads.

Sub-processors are reviewed annually.

8. Backups and recovery

A weekly cycle means up to seven days of exposure. For a broker adding listings daily, a failure the day before a backup loses a week of work. That is an accepted trade at this price rather than an oversight — but it must be stated to customers plainly rather than left for them to discover, and it is the first thing to tighten when the service can carry the cost.

The restore test is the part that matters. An untested backup is a belief, not a control, and the failure mode — discovering at the worst moment that the backup was empty or unreadable — is the one that ends a hosting business. Log each test with its date and outcome.

9. Customer data portability

A customer may request their data at any time (Terms §5.3).

That verification step is not bureaucracy. "Send me my leads" from an email address that merely resembles the customer's is exactly how a broker's client list would be taken.

10. Retention and deletion

Retention periods are in the Privacy Policy (§8). Two operational rules support them:

• Deletion means deletion. When a retention period expires, records are removed from live systems, and backups containing them age out on the normal cycle rather than being retained specially.
• Deletion is confirmed in writing to the customer when they have asked for it.

Invoices are the deliberate exception — Indian tax law requires them to be kept for 8 years. They contain billing details, never leads.

11. Change management

• All platform code is version-controlled. Every change is a reviewable commit with a message explaining why, not only what.
• Dependency and framework security updates are applied promptly; critical advisories are addressed within 7 days.
• Changes are tested before they reach customer sites. The platform ships with an automated test suite; it must pass before deployment.
• No editing files directly on a production server. A fix that exists only on one server is a fix that is lost at the next deployment and cannot be reviewed.
• Customer sites are not modified without notice, except for security patches, which may be applied immediately and disclosed after.

12. Data minimisation in the product

Controls built into the platform rather than left to discipline:

• The enquiry form collects name, mobile, email and message. Nothing more.
• No advertising or cross-site tracking cookies on hosted sites.
• No third-party script loaded at runtime from a CDN — all libraries are bundled, so no external party silently receives visitor data.
• All form input is validated server-side. Client-side checks are convenience only.
• Rich-text content is sanitised on save and on render, so a stored cross-site-scripting payload cannot execute.
• Sold or withdrawn listings are removed from public view but never hard-deleted, so a mistake is recoverable.

12A. Payment handling (manual UPI)

Payments arrive as direct UPI transfers rather than through a gateway, so reconciliation is a manual control and is written down here rather than carried in someone's head.

• Payments are received into a current account held in the company's name at ICICI Bank, kept separate from personal spending so reconciliation and tax filing stay straightforward. The account number is not published here; it is not needed to pay us and publishing it invites misuse.
• Every payment is matched against a customer using the UTR they send us. Unmatched credits are held and chased, never quietly absorbed.
• A receipt is issued in writing for every payment. With no gateway sending automatic confirmations, this is the customer's only proof of purchase — it is not optional.
• A payment log is maintained recording: date, amount, payer UPI ID, UTR, customer, plan, and term dates. This is the renewal list and the refund audit trail.
• Renewal reminders are sent manually at 30 days and 7 days before expiry. Nothing auto-debits, so a missed reminder is a lost renewal rather than an unwanted charge.
• Refunds are sent to the paying UPI ID and recorded against the original payment.

The payment log and leads database are backed up on the same weekly cycle as customer sites (§8). They are business-critical from the day the lead endpoint ships: they hold every enquiry, every payment record, and the renewal dates the business runs on. A backup that has never been restored is a belief, not a control — the restore test in §8 covers this database too.

Known limitation, recorded deliberately: at meaningful customer numbers this becomes the operational bottleneck of the business — a few hundred renewals a year is a few hundred manual reminders, matches and receipts. Revisit a payment gateway or a UPI Autopay mandate when the reconciliation effort exceeds its cost, not before.

13. Incident response

If a security incident is suspected:

1. Contain — isolate the affected site, rotate exposed credentials.
2. Assess — determine what data was involved, whose, and over what period. Record findings as they are established, not after.
3. Notify — per Privacy Policy §11: the Data Protection Board of India as the DPDP Act requires, and the affected customer within 72 hours of becoming aware.
4. Support the customer's own duty — where their visitors' data is affected, they must notify those individuals as Data Fiduciary. Give them the facts they need to do it.
5. Remediate and record — fix the cause, write down what changed, and review this policy.

Do not delay notification while investigating. Tell the customer what is known, that the investigation is ongoing, and when the next update will come. Silence during an incident is what turns a technical problem into a lost customer.

14. Business continuity

Quick Web Go is operated by a small operations team rather than by one person, so no single individual's absence takes the service down.

Alongside that, the architecture carries most of the load. Every customer website is a separate, independent deployment on third-party hosting paid for in advance. Your site does not depend on anyone being at a desk: it serves pages, captures enquiries into its own database, and keeps doing so without intervention. Code is held in version control and your data is exportable at any time.

Those last rows cost nothing to promise while small and are worth a great deal to a cautious buyer. They also force a wind-down to be handled decently if it ever happens.

15. People

• Anyone with access to customer data signs a confidentiality undertaking before receiving it.
• Devices used to access production carry a screen lock, full-disk encryption, and current OS security updates.
• Customer data is not copied onto personal devices, personal cloud drives, or personal email for convenience.
• Anyone may raise a security concern without blame. A near-miss reported is worth more than an incident concealed.

16. What we do not claim

Stated deliberately, because a policy that claims everything is worth nothing:

• We are not ISO 27001 or SOC 2 certified. We do not claim to be.
• We do not operate a 24×7 security operations centre.
• We do not offer a contractual uptime guarantee on Starter or Pro plans.
• We do not guarantee that no incident will ever occur. Nobody honestly can.

What we do commit to is proportionate, documented, actually-operated security, and telling you the truth quickly when something goes wrong.

17. Review

Reviewed every 12 months and after any incident. Material changes affecting how customer data is handled are notified to customers at least 30 days before taking effect.

Change log