What your reviewer needs, before anyone signs.

What a procurement pack is for

Most enterprise reviews do not fail because the product is weak. They stall because the vendor cannot produce a document, produces three versions of it, or answers a questionnaire with a claim that the public security page contradicts. A procurement pack exists to remove that stall: it is a fixed set of documents, each dated, each owned, each consistent with the others and with the website.

This page is written for the person doing that review, not for the person approving the budget. It explains what is in the pack, how the sample SLA is built, how support is staffed against severity, and where the gaps are. It is deliberately unexciting. There are no badges, no implied certifications and no uptime chart, because none of those exist yet and a trust surface that borrows them is worth less than no trust surface at all.

One distinction runs through everything below. A security page describes what a company says about itself. A procurement pack describes what a company will sign. The first is marketing with better vocabulary. The second is evidence you can attach to an internal risk file and defend six months later, when your auditor asks who approved the vendor and on what basis.

Two limits apply to the whole page. Nothing here is legal advice, and nothing here overrides a signed agreement. If a sentence on this page and a clause in your contract disagree, the contract wins and we will correct the page. Where a document is named, the document is the source; where a term is described, the order form is the source.

The seven items in the pack

The pack is seven documents, sent as one folder rather than in a drip. Each carries a version, a date and an owner, so a reviewer can tell whether they are reading last quarter’s architecture note or this week’s. The folder is the same for every buyer; what changes is the questionnaire you send and the redlines you add.

The questionnaire answers are our completed responses to your form, plus the standard set we maintain for buyers who do not have one. Rows we cannot answer fully are marked partial with a reason, rather than left blank or answered with a yes that a follow-up call would unpick. An answer that survives one call is worth more than a perfect score that collapses on the second.

The architecture and data-flow annexe is described in the next section. The sub-processor list is the published table at /subprocessors/, with a purpose and a region for each vendor, and it is the same table the DPA refers to rather than a separate procurement copy that can drift. The DPA is the published agreement at /dpa/.

The sample SLA is the draft schedule described later on this page: measurement, exclusions, credits and claims, ready to be negotiated into the order form. The penetration-test summary status is a one-page statement of where testing stands, including the honest answer when no report exists. The business continuity note covers backups, restore procedure, dependency map and the communication path during an incident; it is a self-assessment, not an audited attestation.

• Security questionnaire: your form or our standard set, with partial rows flagged and explained.
• Architecture and data-flow annexe: data classes, storage, sub-processors and transfer paths.
• Sub-processor list: five vendors, each with purpose, region and a contractual change notice.
• DPA: roles, documented instructions, security schedule, breach notice, deletion and audit.
• Sample SLA: two measured surfaces, named exclusions, a credit schedule and a claim route.
• Penetration-test summary status: what has been tested, what has not, and what is shared under NDA.
• Business continuity note: backup regime, restore procedure, dependencies and communications.

The architecture and data-flow annexe

The annexe is the document a security architect reads first, and the one most often missing from a vendor pack. It lists each data class the platform handles, where that class is stored, which sub-processor can see it, how long it is kept and what protects it in transit and at rest. Data classes are named in the customer’s language: contact records, message content, call recordings and transcripts, support attachments, billing details and audit events.

It also states the paths that leave India, because a residency claim that ignores the edge is not a residency claim. Primary storage and processing are in AWS Mumbai, region ap-south-1. Cloudflare terminates TLS and serves the site at a global edge. Postmark carries transactional fallback email from the United States. Datadog holds observability data in the United States or the EU. Razorpay handles payments in India. Each is named with the data class it can touch.

The annexe is the right place to test a requirement rather than a marketing line. If your policy says no personal data may be processed outside India, the annexe shows where that is not achievable today and which workflow causes it, before signature rather than after. We would rather lose a deal at that point than discover the mismatch during an audit, when the cost of change lands on the customer.

What the annexe is not: a network diagram of every internal service, a list of every library in the build, or a promise that no data ever moves. It is a document about personal data paths, written to be read by someone who has to decide whether those paths are acceptable for a specific workload.

The sample SLA: two surfaces, one clock

The sample SLA covers two surfaces, because those are the two we can measure from outside without touching customer data: the production API and the marketing site. The API is checked with an authenticated read and a write on a fixed schedule, so a healthy login page cannot mask a stalled queue. The site is checked with a request for the home page and the pricing page, because those are the pages a buyer and a crawler actually load.

Availability is the number of successful checks divided by the number of scheduled checks in the calendar month, expressed as a percentage, with the month running from 00:00 to 23:59:59 IST. Checks run at least once a minute from at least two vantage points, one of them in India, through a provider whose results both parties can query. The monitor of record, its interval and its vantage points are named in the schedule, because a percentage without a method is not measurable and therefore not enforceable.

The target in the draft is 99.5% monthly availability for the API and the site. That figure is a drafting example, not a measured result and not a public promise. The number that binds is the one written into your order form, and it may be higher, lower, or replaced by a different construction such as a monthly error budget. No uptime history is published yet, so there is no track record to point at. Measurement begins when the monitor is attached to your workspace, and the first month is the first month.

The measurement has limits that belong in the schedule itself. A synthetic check proves reachability and a scripted transaction; it does not prove that every workflow, template or voice route is correct. Voice and WhatsApp availability depend on telecom operators and Meta, and they sit outside the two-surface target unless a separate schedule names them. A month with no usable checks, because the monitor was misconfigured, is not a month at one hundred per cent.

Exclusions, credits and claims

Exclusions are where an SLA is won or lost in practice, so the draft lists them instead of burying them. Time does not count against availability when the failure is on the customer’s side of the boundary: DNS records and CNAMEs the customer controls, the customer’s ISP or last-mile network, a webhook endpoint that returns errors, or a configuration change in the workspace that removes a required permission.

It also does not count when the cause is a third-party platform we do not operate and cannot route around: Meta’s WhatsApp platform, telecom operator networks and DLT registration, upstream model providers, and payment gateways. Scheduled maintenance announced at least 72 hours ahead is excluded, with the window in IST and the affected surfaces named. Force majeure is excluded on the usual terms. None of this removes our obligation to communicate: an outage caused by a dependency is still an incident, still gets an update, and is still reviewed.

Credits follow a percentage schedule rather than a negotiation after the fact. In the draft, availability below 99.5% and at or above 99.0% earns 5% of the monthly fee for the affected surface; below 99.0% and at or above 98.0% earns 10%; below 98.0% earns 25%. The credit is capped at 25% of the monthly fee for that month, is applied to the next invoice rather than paid in cash, and is the sole remedy for an availability shortfall under the draft. Credits are calculated per affected surface, not per incident.

The claim route is deliberately short. Raise the claim within 30 days of the end of the month through your support channel or procurement contact, with the workspace identifier, the surface and the times you observed in IST. We reconcile against the monitor of record, share the check data, and respond within 10 business days. If the two sets of data disagree, the schedule names which one governs and how a dispute is escalated; that clause is negotiated, not assumed.

One more sentence belongs here. An SLA is a set of numbers with a remedy attached, and a remedy that has not been priced into a contract is a marketing sentence. The draft exists so that your legal team has something concrete to mark up. It is not an offer to every reader of this page.

The support matrix: severity, not sentiment

Severity is assigned by impact, not by the tone of the ticket, and the first response target depends on severity and plan together. The definitions below are the ones used in the draft schedule; the same words should appear in your order form if support terms are contractual for you.

P1 is a production outage or a security event: the API or a core channel is unavailable for all users, data loss is suspected, or there is unauthorised access, and there is no workaround. P2 is a major function degraded with a workaround: one channel failing while another works, elevated error rates, or a workflow that runs but produces wrong output at volume. P3 is a minor issue confined to a single workflow, a report, a template or the interface. P4 is a question, a how-to, a documentation error or a feature request.

First response means a qualified human acknowledging the issue, restating the impact as understood, naming an owner and giving the next update time. It does not mean a fix, a root cause or an ETA, and any vendor that treats the two as the same is measuring the wrong thing. Update cadence is separate from response: a P1 gets an update at least every 60 minutes while it is open on Scale, every four hours on Growth, and daily on Starter, or as agreed in the schedule.

Escalation follows a named path rather than a hope that the account manager notices. A P1 opens an incident channel with a commander whose job is coordination rather than debugging. The technical account manager on Scale and the named customer success manager on Enterprise join customer calls and own the written review. Management escalation goes to the contact named in the order form, and it is available on every paid plan, including when the original ticket was opened on a weekend.

• P1: outage or security event, no workaround, incident commander assigned.
• P2: major function degraded, workaround exists, engineering owner named.
• P3: one workflow, report, template or interface issue, with a single owner.
• P4: question, how-to, documentation error or feature request, answered in writing.
• Free: community only, with no severity commitment and no response target.

Which plan gets which target

Plan mapping is the part buyers check against the pricing page, so it uses the same words. Free is community support: documentation, the changelog and the community forum, with no response target and no severity commitments. Starter includes email support with a target of one business day, which is the 24-hour figure on the pricing page read as a business-day target rather than a wall-clock promise.

Growth includes priority support with a four-hour first response during business hours and a separate queue. Scale includes 24/7 cover with a one-hour first response and a named technical account manager. Enterprise adds a named customer success manager, phone access and negotiated terms; where an enterprise agreement sets a shorter target, the agreement governs and this page does not restate it.

Business hours are 09:00 to 18:00 IST, Monday to Friday, excluding Indian public holidays. A four-hour target outside those hours means the clock starts at 09:00 on the next business day, which is the honest reading and the one to plan an escalation rota around. If your operations run at 02:00 IST, the plan that matches that is Scale or Enterprise, not Growth with an expectation attached.

Two expectations are worth correcting before signature. A response target is not a resolution target: a P1 fix can run for hours beyond the first reply, and the update cadence is the commitment during that time. A technical account manager is a named person who knows your architecture and joins escalation calls; they are not a dedicated engineer sitting on your account, and a plan that included one would be priced differently.

The security review, end to end

The review runs in five steps, and the order matters because each step produces something the next one needs. Step one is a mutual NDA, on your paper or ours, signed by someone who can bind the company. Step two is the questionnaire, sent with the workspace context that changes the answers: which channels, which data classes, which integrations, which regions.

Step three is the evidence pack. It goes out with the questionnaire answers rather than after them, because a reviewer who has the architecture annexe stops asking questions the annexe already answers. Step four is the penetration-test summary: a one-page statement of scope, date, tester, findings by severity and remediation status, shared under NDA when a test has been completed, and a written status when it has not.

Step five is a 60-minute call with the engineer who owns the architecture and the person who can accept residual risk on your side. The call is not a sales demo. It is where the annexe is tested: what happens to a recording, which vendor sees a prompt, how a deletion propagates, and what the monitor actually checks.

A standard review takes five to ten business days when the pack and the questionnaire arrive together, and three to four weeks when they arrive in batches. The difference is almost never a control gap; it is documents requested one at a time. If your reviewer needs an artefact we have not listed, ask for it by name and we will either send it or say plainly that it does not exist.

Penetration testing and continuity: what exists today

The penetration-test position is short. No independent test report is published today, and no test date is quoted on this page. The DPA commits to annual penetration testing from 2027. When a test has been completed, a summary can be shared under NDA covering scope, methodology, tester, findings by severity and remediation status. We will not describe a test as complete before the report exists, and we will not describe a scope we did not commission.

The scope of a test matters as much as its existence. A test of the production API and the marketing site does not cover a customer’s own workflow configuration, the connected third-party systems, or their prompts. A report that says no critical findings is a statement about the tested surface, and reading it as a statement about every deployment is a mistake buyers make when the summary is written to encourage it.

Alongside testing sits vulnerability intake. Reports go to security@loopnow.in or the contact in /.well-known/security.txt, are acknowledged within one business day, and are handled without requiring a restrictive agreement first. Coordinated disclosure is welcome. Testing against customer data, denial-of-service attempts and social engineering of staff are not.

The business continuity note covers the backup regime, the restore procedure, the dependency map and the communication path during a regional event. It is a self-assessment written by the team that operates the platform, and it says so on its first page. It does not contain a tested recovery time objective. We will publish an RTO when a restore exercise produces one, not before, because an untested RTO is a number that fails at the worst possible moment.

What we do not offer yet

The gaps are listed in the same place as everything else, because a trust surface that only lists strengths is a brochure. There is no SOC 2 Type II report. There is no ISO 27001 certificate; the audit is in progress with a target of Q3 2027 and no certificate exists today. There is no public uptime history: the status page is a template with no monitor connected and no percentage published.

Support gaps matter just as much. There is no 24/7 phone line on self-serve plans; round-the-clock cover begins at Scale through the support portal, and phone access is an Enterprise term. There is no dedicated on-premises deployment on self-serve; private VPC is an Enterprise conversation. There is no audited continuity attestation, only the self-assessment note. And deletion is not a sweep across every system: live records are removed on request, backups expire on their rotation schedule, and consent records are kept as evidence. We do not describe that as an automated retention sweep, because it is not one.

Where a gate is absolute, the honest answer is that we are not the right vendor this quarter. A bank that cannot onboard a processor without a SOC 2 report should not accept a roadmap slide instead, and a team that needs a public ninety-day uptime chart should not accept a promise that one is coming. We will say that on the first call rather than the fifth, and we will tell you what would change the answer.

What is available today is narrower and real: the DPA and the sub-processor list, the architecture annexe, completed questionnaire answers, a sample SLA with a credit schedule, a documented support matrix, a vulnerability intake that answers within one business day, and a named person on the procurement thread who is allowed to say no.

Invoicing, PO and the legal mechanics

Commercial mechanics are where procurement and finance meet, so they are stated without hedging. Prices are in Indian rupees and exclusive of GST. GST is added at 18% as a separate line: CGST and SGST for an intra-state supply, IGST for an inter-state supply, based on the GSTIN and state on the billing profile. The invoice is issued to the legal entity that signs the order form, not to the individual who happens to pay.

The PO process is ordinary. Send the purchase order with the order form, or reference the PO number in the order form and we will carry it on the invoice. If your finance team cannot release a payment without a PO that references a signed contract, say so before the order form is issued and the sequence can be arranged. Payment runs through Razorpay for cards, UPI and net banking, and annual plans can be paid by NEFT. The invoice follows the payment route rather than the other way round.

The DPA is signed alongside the order form, not months later. The published version at /dpa/ is the starting text, and redlines are answered in writing with a reason rather than accepted verbally on a call. The sub-processor list is a schedule to the DPA, so a change to that list is a contract event with notice, not a product update. Where a customer needs a negotiated security schedule, it sits in the order form and the DPA refers to it.

The agreement is governed by Indian law, and the courts at Mumbai have exclusive jurisdiction. The contracting entity is LoopNow Technologies Pvt. Ltd., Bhayandar West, Mumbai, Maharashtra 401101. Nothing on this page is legal advice, and nothing here overrides a signed document; where the order form, the DPA and this page disagree, the signed documents govern and we will correct the page.

Running the review in one pass

Most reviews that run long do so for structural reasons, and they are avoidable. Send the NDA, the questionnaire, your DPA redlines and any residency or retention requirements in one message to the procurement contact, and name the person on your side who can accept residual risk. A review with a named decision-maker ends in a decision. A review without one circulates.

Three questions decide most of these evaluations, and they are worth answering before the questionnaire. Where does personal data go, including the paths out of India? What happens to it on deletion, and which copies expire later? What availability and support commitment will be signed, and what is the remedy if it is missed? The pack answers all three, but only if the reviewer reads the annexe and the SLA schedule rather than the summary.

The slowest pattern is a redline negotiation that starts after signature, when the commercial leverage has gone and a security team is asked to accept something legal already promised. The second slowest is a request for a certificate that does not exist, made in week three, after two weeks of questionnaire work. Both are solved by sending the hard requirements first.

The sequence below is elapsed days for a mid-market review with the pack complete: NDA on day zero, questionnaire returned by day two, evidence reviewed by day four, call on day six, signature around day eight, invoice and kickoff by day ten. It is not a commitment, and it assumes your reviewer and ours are both available. It exists so that a first call can start from a shared shape instead of a blank calendar.