You found three critical vulnerabilities, reported all of them responsibly, watched the vendor throw a tantrum in a meeting instead of fixing anything — and now the organization wants YOU to take over. That’s not luck, that’s earned trust. But here’s the part nobody tells you: the skills that got you this opportunity are completely different from the skills that keep you safe inside it.
Right now, today — get written authorization from the organization before touching any system. One page. “We authorize [your name] to audit, assess, and transition our web infrastructure.” Without this, your previous vulnerability discoveries technically expose you under India’s IT Act Section 66 (up to 3 years + ₹5 lakh fine — India has zero safe harbor for security researchers). That signed paper retroactively reframes everything you did as authorized work.
This weekend — run a baseline security audit on every site and the mail server using WPScan + OWASP ZAP. Screenshot everything. Hash every report file (SHA-256). This timestamped “here’s how broken it was BEFORE I touched it” document is worth more than any contract clause — it proves every existing vulnerability belongs to the old vendor, not you. I use WPScan for exactly this on inherited WordPress sites — takes 20 minutes per site and catches things manual review misses.
| Your concern |
What actually works |
When |
| “What documents?” |
One MSA (Master Service Agreement) with per-project SOWs — not 10 separate contracts |
Before signing anything |
| “Legal protection?” |
“Pre-existing conditions” clause + baseline audit artifact + PI insurance (₹10K-50K/year via SecureNow) |
Week 1 |
| “Which of the 3 options?” |
Option 2 (develop on their server) with IP license — you retain ownership, they get usage rights. Maximum protection without maximum liability |
Decide before first SOW |
| “10+ projects efficiently?” |
Shared WordPress multisite or identical stack across all sites + one WhatsApp Business API account serving all sites through Gupshup or AiSensy |
Architecture decision, Week 1 |
| “Unclear requirements?” |
Don’t start building. Run a 2-hour requirements session: show them 5 competitor sites, ask “like this or not like this?” for each. Vague clients can’t describe what they want — but they can react to what they see |
Before any development |
| “Long-term security?” |
Monthly retainer (₹25K-60K/mo for all sites) covering updates + security monitoring + DPDP compliance. Build once, maintain forever > project-by-project feast-or-famine |
Structure into MSA |
The vendor who told the org to “switch if not satisfied” — that person still has DNS access, hosting credentials, and admin panels until you rotate every single one. Hostile vendor transitions have a 48-72 hour danger window. Domain lock + registrar-level transfer + full backup BEFORE announcing the switch. Not after.
🔐 The Full Playbook — Do Exactly This, In This Order
Phase 0 — Protect Yourself (Before You Write a Single Line of Code)
The ₹786/month insurance trick: Bajaj Allianz offers Professional Indemnity insurance starting at ₹786/month for up to ₹1 crore coverage. For a freelancer about to manage 10+ websites for one organization, this is non-negotiable. One data breach without PI insurance = personal liability. One data breach WITH PI insurance = the insurer’s problem. Apply through Bajaj Finserv or compare on Plum HQ.
Step 1 — Get written authorization (one page, signed by the org’s decision-maker, explicitly covering audit + transition + ongoing management)
Step 2 — Run baseline security assessment on ALL sites + mail server. Tools: WPScan (WordPress vulns), OWASP ZAP (web app scanning), testssl.sh (SSL config). For each site, document: WordPress version, every plugin with version and last update date, all user accounts, server config, file permissions. Hash every output file with SHA-256. Both you and the client sign the completed report — this is your legal “not my fault” artifact.
Step 3 — Draft your MSA under the Indian Contract Act. India-specific things US/UK templates miss:
- TDS: Client must deduct 10% tax at source (Section 194J) and give you Form 16A
- Stamp duty: Must be on non-judicial stamp paper (rates vary by state — check your state). Unstamped = inadmissible in court per the Supreme Court’s 2023 In Re: Interplay ruling
- Non-compete clauses are void in India (Section 27, Indian Contract Act). Don’t sign one, don’t ask for one
- Liability cap: Indian courts only enforce “reasonable compensation” (Section 74). Cap at total fees paid, exclude indirect damages, carve out confidentiality breaches
- GST: If your total annual billing exceeds ₹20 lakh, you need GST registration. IT services = 18% GST. Specify whether your quotes are GST-inclusive or exclusive
The “pre-existing conditions” clause that saves you: Include this exact concept: “All findings documented in the Baseline Security Assessment represent pre-existing conditions. [Your name] assumes no liability for vulnerabilities, misconfigurations, or security issues identified during the baseline assessment period.” Attach your signed baseline report as an exhibit to the MSA.
Step 4 — PI Insurance. ₹10,000-50,000/year for ₹25-50 lakh coverage. Providers: HDFC ERGO, Bajaj Allianz, TATA AIG, ICICI Lombard. Go through a broker (SecureNow or Mitigata) — they customize for IT freelancers. Add cyber insurance if budget allows (combined PI + cyber = ₹25K-75K/year).
Phase 1 — The Hostile Vendor Transition (The Dangerous Part)
The old vendor has every reason to make your life difficult. Here’s the sequence that prevents sabotage:
Step 5 — Before telling the vendor anything: get the domain registrar login (not just hosting — the REGISTRAR). Enable domain lock. Set up auto-renewal. Change registrar password. This is the single most important credential — if the vendor lets the domain expire or redirects DNS, everything dies.
Step 6 — Full backup of everything: files (FTP/SSH download entire web root), databases (mysqldump), email (export all mailboxes), DNS zone file (export from registrar or hosting panel). Store locally AND in a separate cloud backup the old vendor can’t access.
Step 7 — NOW tell the vendor. Migrate hosting. Reissue SSL certs. Update MX records for email. Rotate EVERY credential: CMS admin, cPanel/SSH, FTP, database, email accounts. The old vendor should have zero access to anything within 48 hours of the announcement.
The mail server problem you created (and how to fix it): You told the org you could take control of their email. That means you KNOW the vulnerability exists. The moment you become their vendor, you’re legally the person who knew and didn’t fix it. Remediate this in your FIRST week — not as a favor, as self-preservation. Document the fix in writing.
Phase 2 — Stack Decision + WhatsApp Reality Check
Step 8 — For 10+ “informative websites” with CMS, WordPress multisite or identical single-site installs with a shared theme and plugin stack is the only sane choice. Same updates across all sites, same security config, shared component library. Building 10 unique codebases as a solo developer = burnout in 3 months.
Step 9 — WhatsApp chatbot integration requires the WhatsApp Business API (not the free WhatsApp Business App). The free app can’t do chatbot flows. To get API access, the org needs:
- GST Certificate (fastest verification document for Indian orgs)
- Meta Business Manager account with verified business
- A dedicated phone number not on any existing WhatsApp account
- A live website with a privacy policy
The cost nobody mentions upfront: WhatsApp Business API charges per conversation. Marketing messages = ₹0.88 each. Utility messages = ₹0.13 each. Customer-initiated service messages = free for 24 hours, then paid. Plus BSP monthly fees (₹999-5,000/mo). For 10 informative websites, one API account + one BSP serves all sites. Don’t set up 10 separate accounts — one Gupshup or AiSensy account with per-site routing costs 90% less.
Phase 3 — The Legal Layer Nobody Thinks About Until It’s Too Late
Step 10 — India’s DPDP Act 2023 applies to EVERY contact form, newsletter signup, and WhatsApp chatbot interaction on those 10+ sites. Full enforcement: May 13, 2027. No small-business exemption. Penalties: up to ₹250 crore for security failures, ₹200 crore for breach notification failures. Negligence alone is enough — no malicious intent required.
What every site needs: explicit opt-in consent checkbox (never pre-ticked) → linked privacy notice in plain language → mechanism for data access/correction/erasure requests (7-day response SLA) → encrypted data storage → documented retention periods → breach notification procedure (72 hours to DPBI).
Build this into the websites from Day 1. It’s a billable deliverable — add a DPDP compliance line item to every SOW.
The conflict-of-interest paper trail: You found 3 vulnerabilities → the vendor lost the contract → you got the contract. That’s a story someone could spin negatively (“did they plant the bugs to steal the client?”). Protect yourself: ensure your original vulnerability reports have timestamps predating ANY discussion about taking over the project. Keep every email, every message, every report in a folder you never delete. If you reported through email, forward copies to yourself on a separate account as backup. This is probably never a problem — but if the old vendor decides to fight, timestamps are your defense.
Pricing Reality Check (So You Don’t Underbid)
| Service |
Per site |
10-site bundle |
| WordPress informative site (build) |
₹40,000–₹75,000 |
₹3.5–6 lakh |
| WhatsApp chatbot (basic FAQ) |
₹30,000–₹60,000 |
₹2.5–5 lakh |
| Monthly maintenance (all sites) |
₹3,000–₹5,000/site |
₹25,000–₹40,000/mo |
| Annual security audit (VAPT) |
₹20,000–₹40,000/site |
₹1.5–3 lakh/year |
| Year 1 total |
— |
₹8–15 lakh builds + ₹3–5 lakh/yr maintenance |
Your security background justifies pricing at 20-40% above typical freelancer rates. The org just watched their cheap vendor get exposed three times — they’re not price-shopping right now, they’re trust-shopping. Price for the value, not the market.
Your Situation → What to Do
| If you’re… |
Do this |
Skip this |
| Starting conversations with the org |
Get written authorization + baseline audit + MSA drafted |
Don’t agree to scope/pricing yet |
| Choosing between the 3 options |
Option 2 (dev on their server + IP license) |
Option 1 (selling code = giving away leverage) |
| Solo and worried about 10+ projects |
Phase the work: 3-4 sites first, rest in batches. Tell the org upfront |
Don’t promise all 10 simultaneously |
| Thinking about pricing |
₹5-8 lakh total build + ₹30-40K/month retainer |
Don’t charge hourly — scope creep kills hourly billing |
| Worried about the old vendor |
Secure domain registrar FIRST, backup everything BEFORE announcing switch |
Don’t tell the vendor before you have backups |
You mentioned the org gave you three options and you’re trying to figure out the safest path forward — honestly, Option 2 with a solid IP license agreement is the sweet spot for your situation. You keep ownership of what you build, they get usage rights, and if the relationship ever sours you’re not starting from zero. One thing I’d want to know before giving more specific advice: is this organization a government/semi-government body or a private company? That changes the contract structure, payment timelines, and TDS implications pretty significantly.
!