/blog/fortiweb-30-60-90-deployment-playbook
FortiWeb 30, 60, 90 day deployment playbook
Published 20 Jul 2026
· By
Pawan Sharma
· Network Security
· 13 min read
FortiWeb deployment fails the same way every time it fails — too much production traffic pushed onto an under-tested policy, missing rollback paths, logging integration missed until the first real incident, HA pair config drift discovered during failover testing. The 30-60-90 playbook below is the work pattern that avoids those failures. Built from typical Indian enterprise deployments — adjust the pace to your specific risk tolerance.
Day 0-30
Foundation
Procurement, deploy, monitor-only, ML baseline.
Day 30-60
Cutover
Phased enforce per app. 2-5 endpoints per week.
Day 60-90
Integration
FortiAnalyzer / FortiSOC, runbook, knowledge transfer.
Day 90+
Steady-state
Quarterly review, renewal management, tabletop exercise.
Day 0-15 — Procurement + foundation
Day 1 — Sizing finalised + PO raised
Shape, tier, term, HA topology all confirmed. INR + GST PO to Ogma. For HW: lead time noted (2-3 wk standard models, 4-6 wk for 4000F).
Day 1-3 — Architecture design
Network topology drawing, IP plan, HA design, FortiAnalyzer integration plan, log retention scope. Sign-off from network + security.
Day 5-10 — Pre-staging
HW: appliance arrives, Ogma pre-stages config in lab. VM: BYOL licence applied to pre-built AMI / VM image. FortiAppSec Cloud: tenancy provisioned.
Day 10-15 — Install + connectivity
HW rack + cable. VM deployment. Verify connectivity, HA pair sync, FortiCloud registration, FortiAnalyzer log forwarding test.
Day 15-30 — Policy foundation + ML baseline
Day 15-18 — App inventory + schema import
List all apps to protect. Import OpenAPI / Swagger / XML / JSON schemas. Initial positive-security policy in monitor mode.
Day 18-25 — Production traffic in monitor mode
FortiWeb sees real traffic, doesn't enforce. Continuous Learning ML builds the behavioural baseline per app. Track candidate detections; don't block yet.
Day 25-30 — Initial tuning
Review candidate detections from the monitor week. Tune signature thresholds, allow good bots, configure JS challenges. Reduce projected false-positive rate to operational floor (typically < 0.1%).
Day 30-60 — Phased cutover to enforce
Day 30 — Lowest-risk endpoint enforce
Pick one endpoint. Lowest risk = lowest user impact if false-positive. Health check, search, public docs typical. Flip enforce mode. Watch metrics for 24-48 hours. Rollback path: documented in runbook.
Day 32-40 — First cohort
Add 4-6 more low-risk endpoints. Watch false-positive rate, ML drift, latency. Daily sync to triage anything unexpected.
Day 40-50 — Production cutover wave 2
External non-card production endpoints. APIs, account pages, listings. 2-5 per week. Rollback per endpoint if false-positive impact > tolerance.
Day 50-60 — High-risk endpoints last
Login, signup, payment pages. One per week max. 72-hour close watch each. ATO protection + Credential Stuffing Defense engaged and tuned per endpoint.
Day 60-90 — Integration + handover
Day 60-65 — FortiAnalyzer integration end-to-end
All FortiWeb logs to FortiAnalyzer. Retention policy applied (180-day default for CERT-In compliance). Dashboards configured.
Day 65-72 — SIEM / SOC integration
FortiAnalyzer → SIEM connector. Incident tickets route to SOC queue. SOC team trained on FortiWeb incident triage.
Day 72-80 — Runbook + incident playbooks
Documented procedures: WAF outage handling, false-positive triage, attack-confirmed escalation, emergency policy push, HA failover test. Sign-off from operations.
Day 80-85 — HA failover test
Scheduled failover during maintenance window. Verify automatic failover, log continuity, policy sync, recovery time. Document any drift.
Day 85-88 — Knowledge transfer
Operations team takes over Day-2 operations. Ogma in supporting role.
Day 88-90 — Closeout review
Metrics review: false-positive rate, attack-block volumes, latency impact, ticket counts. Lessons-learned doc. Renewal cycle planned.
Common pitfalls + mitigations
| Pitfall | How it bites | Mitigation |
|---|---|---|
| DNS TTL not pre-shortened | Rollback takes hours instead of minutes | Shorten TTL to 60-120 sec ~1 week before cutover; restore after stable |
| Logging integration missed | First incident: no logs in SIEM | End-to-end test at Day 30; replicate test before each cutover wave |
| HA pair config drift | Failover fails or partial | Day 80-85 failover test catches this; quarterly thereafter |
| ML baseline not stable before enforce | High false-positive rate at cutover | Minimum 7-10 days monitor-only per app before enforce |
| Bot ceiling exceeded | Advanced Bot Protection silently degrades | Size HW model / VM tier with bot-ceiling headroom from Day 1 |
| Schema drift vs production | Real traffic doesn't match declared schema; high FP rate | API Discovery (Advanced+) catches this; review schema vs traffic at Day 20-25 |
| Custom rule overlap | Two rules fight each other | Rule prioritisation reviewed at Day 25-30; documented matrix |
FAQ
Can the deployment happen faster than 90 days?
What's the highest-risk step?
How many endpoints can move per week in Day 30-60?
What about ML model training time?
Who needs to be in the room on Day 1?
What's typically missed?
Does the playbook change for FortiAppSec Cloud (SaaS)?
What about post-90-day operations?
Engage Ogma for the 90-day FortiWeb deployment
Single engagement — procurement, deploy, tune, integrate, hand over
Ogma's FortiWeb implementation engagement runs the full 90-day playbook. Fixed scope, fixed deliverables, INR + GST quote. Your team takes over Day 90 onward.
Request the engagement or explore the Implementation service landingSources
- FortiWeb Data Sheet — feature deployment characteristics
- FortiWeb Ordering Guide — bundle structure, renewal SKUs
Related: FortiWeb Implementation service · FortiWeb Installation service · HW sizing guide
Stay ahead of cyber threats
One short email a week — curated Indian cybersecurity news, Fortinet releases, DPDPA updates. No fluff.
