FAQ

• What does Quisitive Businesses do?
  Quisitive Businesses is a managed security and IT infrastructure company. We design, implement, and operate the technology foundations that enterprises depend on — security operations, network and infrastructure monitoring, cloud deployment, and data centre engineering. Our services are delivered as managed engagements, meaning we take operational responsibility for the outcomes rather than handing over a recommendation document and stepping away.
• Who are your services designed for?
  Our services are designed for mid-market and enterprise organisations that run complex, business-critical IT environments and need specialist capability that would be difficult, expensive, or slow to build entirely in-house. This includes organisations in Banking & Financial Services, Healthcare, Manufacturing, Government, IT/ITeS, and Technology sectors — as well as growth-stage companies that have outgrown the level of security and infrastructure support their current arrangements provide.
• Are your services suitable for organisations that already have some IT and security capability in place?
  Yes — and this is actually the most common starting point. Most organisations we engage with have existing IT teams, some security tooling, and partial infrastructure in place. Our services complement and extend what you already have — filling the gaps in coverage, expertise, and operational capacity — rather than replacing your existing team or requiring you to start from scratch.
• What industries do you have the most experience working in?
  Our service capability spans Banking & Financial Services, Healthcare, Manufacturing & Industrial, Government & Public Sector, IT/ITeS, Technology, and Retail & E-Commerce. Each of these sectors has distinct compliance requirements, threat profiles, and infrastructure constraints — and our delivery approach is scoped to those specifics rather than applied generically across all engagements.
• Are you a product company or a services company?
  We are a services company. We do not manufacture or resell hardware, cloud platforms, or security products as our primary business. We are vendor-agnostic — meaning we recommend and work with the platforms that are right for your environment, not the ones that generate us the highest margin on a product sale. Our revenue comes from delivering and managing services — which means our interests are aligned with the quality of the outcome, not the size of a one-time product transaction.
• Do you work with organisations outside India?
  Our primary market is India — where we serve enterprises across all major metros and industry verticals. We also support organisations with Indian operations that are part of global groups, and can engage with international organisations requiring managed security or infrastructure services in the Indian market. If your requirement is based outside India, a scoping conversation is the right starting point to determine whether the engagement is a fit.

Managed Security Services (MSSP)

• What is a Managed Security Services Provider (MSSP) and what makes it different from a standard IT provider?
  An MSSP is a specialist organisation that takes on the ongoing operational responsibility for your security posture — monitoring, detecting, responding to, and reporting on threats across your IT environment. The key difference from a standard IT provider is depth of security specialism and operational continuity. An MSSP operates a Security Operations Centre, uses advanced SIEM and threat detection tooling, employs certified security analysts, and is accountable to defined security SLAs — not just general IT availability metrics.
• What does a managed security service actually include on a day-to-day basis?
  On a given day, our managed security service includes continuous ingestion and correlation of log data from your endpoints, firewalls, cloud workloads, and applications; real-time triage of security alerts by our SOC analysts; escalation and response to confirmed threats per agreed runbooks; threat hunting activity for indicators of compromise that have not yet surfaced as alerts; and ongoing tuning of detection rules to reduce false positives and improve signal quality. Monthly, you receive a threat summary report and SLA performance review.
• How quickly can you detect and respond to a threat in our environment?
  Our standard SLA for initial threat triage is 15 minutes from alert generation during monitored hours — which for our SOC service is 24 hours a day, seven days a week. Confirmed incident escalation to your designated contact happens within the response window defined in your service agreement. The specific SLA windows are scoped to your requirements and documented in the managed security services contract before the engagement begins.
• Do we need to replace our existing security tools to work with you?
  No. We are designed to integrate with existing tooling — your SIEM, EDR platform, firewalls, and other security controls. We conduct an assessment of your current stack, identify gaps, and integrate what you have into our monitoring framework. You only invest in new tooling where genuine gaps exist and where the value of that investment is clearly justified. We have no financial incentive to recommend unnecessary tool replacement.
• What compliance frameworks does your MSSP service support?
  Our managed security services are structured to support a range of regulatory and compliance frameworks, including ISO 27001, SOC 2 Type II, HIPAA, PCI-DSS, and India-specific frameworks including the RBI Cybersecurity Framework and SEBI guidelines. Compliance support is scoped at the engagement level — we align monitoring, reporting, and evidence management to the specific frameworks applicable to your organisation rather than applying a generic compliance template.
• What information do you need from us to begin a managed security services engagement?
  To scope an engagement accurately, we typically need an understanding of your environment size (number of endpoints, servers, cloud workloads), your existing security tooling, your primary compliance obligations, your current incident response capability, and your priority security concerns. This is gathered during a structured scoping session — not a form on a website — and typically takes 30 to 45 minutes with the right stakeholders in the room.

SOC as a Service

• What is SOC as a Service and how is it different from having a security tool in place?
  A Security Operations Centre (SOC) is the human intelligence layer that sits on top of your security tooling. Tools generate alerts — analysts make sense of them, separate genuine threats from noise, investigate context, and execute or coordinate response. SOC as a Service means you access that analyst capability as a managed service, without needing to build the team, the physical facility, the tooling stack, and the shift roster yourself. A security tool without a SOC is like a smoke detector in a building with no fire service — it detects, but no one responds.
• What does your SOC team actually do when they detect a threat?
  When our SOC identifies a confirmed threat — not just an alert, but a validated incident — your designated contact receives an immediate notification with full context: what was detected, where it originated, what it appears to be doing, and what initial containment actions we have taken or are recommending. We open a tracked incident record, execute pre-agreed response steps where authorised, monitor for lateral movement or escalation, and begin building the forensic timeline. A post-incident report with root cause analysis follows within 48 hours of resolution.
• Do you use your own SIEM platform or can you work with ours?
  We can do both. For organisations without an existing SIEM, we deploy and manage an enterprise-grade platform as part of the service. For organisations with an existing SIEM investment — Splunk, Microsoft Sentinel, IBM QRadar, or others — we can onboard your environment into our monitoring framework and manage detection on your platform. The goal is effective coverage, not a particular tool preference.
• What is threat hunting and is it included in your SOC service?
  Threat hunting is the proactive search for indicators of compromise that have not yet surfaced as automated alerts — looking for attacker behaviour that is subtle enough to evade standard detection rules but visible to an experienced analyst who knows what to look for. It is included in our SOC as a Service engagement because reactive monitoring alone is not sufficient against sophisticated adversaries. The frequency and focus areas of threat hunting activity are defined in the service scope.
• How do you handle false positives — alerts that turn out not to be real threats?
  False positive management is part of our core service — not an additional request. When our analysts determine that an alert is a false positive, we document it, update the relevant detection rule or exception list to prevent the same alert from recurring unnecessarily, and track false positive volume as a service quality metric in your monthly report. Reducing alert noise is an ongoing engineering discipline, not a one-time configuration activity.

NOC as a Service

• What is NOC as a Service and what does it monitor?
  A Network Operations Centre (NOC) monitors your IT infrastructure for performance, availability, and fault conditions — servers, network devices, applications, internet links, storage systems, and the connections between them. NOC as a Service means you access that monitoring and response capability as a managed service, with defined escalation paths and response SLAs, without building and staffing the monitoring function internally. The NOC handles the operational noise so your internal team can focus on strategic work.
• What is the difference between a NOC and a SOC?
  A NOC focuses on operational continuity — ensuring your infrastructure is available, performing, and functioning as expected. It deals with events like server failures, network outages, high CPU utilisation, and application performance degradation. A SOC focuses on security — detecting and responding to malicious activity, intrusion attempts, and data breach indicators. Both functions monitor your environment continuously, but they monitor for different things and respond through different processes. Many mature organisations operate both, either separately or through an integrated operations model.
• What happens when your NOC detects a performance issue or outage?
  When our NOC identifies a fault — either through automated alerting or through proactive monitoring review — the response follows a defined escalation path. Tier-1 analysts perform initial diagnosis and attempt standard resolution procedures. If the issue requires deeper investigation, it escalates to Tier-2 or Tier-3 engineers. Throughout, your designated contact is notified per the agreed escalation matrix, and the incident is tracked in a ticketing system with full audit trail. Resolution and root cause analysis are documented in every case.
• Can your NOC service cover both on-premise infrastructure and cloud environments?
  Yes. Our NOC as a Service is designed to provide unified monitoring coverage across hybrid environments — physical servers and network devices in your own facilities or colocation, cloud workloads in AWS, Azure, or GCP, and the connectivity between them. This is increasingly important as most enterprise environments span all three, and monitoring each in isolation creates blind spots at the boundaries.
• What SLAs do you offer for NOC response?
  NOC SLAs are scoped per engagement based on the criticality classification of your systems and your operational requirements. Typically, we define response SLAs by incident priority — P1 (business-critical outage), P2 (significant degradation), P3 (non-critical fault), and P4 (advisory/informational) — with defined acknowledgement, update frequency, and resolution target windows for each. These SLAs are documented in your service agreement before the engagement begins, not applied as a standard template after the fact.

Data Centre Consultancy

• What does a data centre consultant actually do?
  A data centre consultant provides independent, engineering-led advisory across the full lifecycle of a data centre facility — from initial feasibility and design through assessment, capacity planning, energy optimisation, migration, and decommission. The value of independence here is significant: a consultant who does not sell hardware, cooling systems, or cabling infrastructure has no financial incentive to recommend a full replacement when optimisation would serve you better, or to overspecify a build to protect a product margin.
• What is a Tier classification and which Tier should our data centre be?
  Tier classification — defined by the Uptime Institute — describes the availability and fault tolerance capability of a data centre facility. Tier I provides basic redundancy with expected annual uptime of 99.671%. Tier II adds redundant components. Tier III (Concurrently Maintainable) allows planned maintenance without shutting the facility down — 99.982% uptime. Tier IV (Fault Tolerant) means a single failure event — planned or unplanned — cannot cause an outage — 99.995% uptime. The right Tier for your facility depends on the criticality of the workloads it supports and the business cost of an outage, not a general preference for the highest number.
• What is PUE and why does it matter to our organisation?
  Power Usage Effectiveness (PUE) is the ratio of total power drawn by a data centre facility to the power consumed by the IT equipment inside it. A PUE of 1.0 would mean every watt entering the facility is consumed by IT equipment — no waste. In practice, a modern well-designed data centre should achieve a PUE between 1.2 and 1.4. Facilities with PUE above 1.8 are consuming significant power on cooling, lighting, and other mechanical systems relative to their IT load — and that represents directly reducible operational cost. PUE also increasingly features in corporate ESG reporting and regulatory frameworks.
• Do you only advise on new data centre builds or can you assess an existing facility?
  Both. Our data centre assessment service is specifically designed for organisations with existing facilities — evaluating current power and cooling utilisation, identifying redundancy gaps, benchmarking against TIA-942 and Uptime Institute standards, and producing a prioritised remediation programme. Organisations considering a new build or major expansion also engage us at the design stage, where independent advisory has the highest leverage and the lowest cost to implement recommendations.
• What does a data centre risk assessment include?
  A data centre risk assessment from Quisitive Businesses covers Single Point of Failure analysis across all critical subsystems — power, cooling, network, and physical security; Business Impact Analysis quantifying the cost-per-hour of outage for different system classes; resilience scoring against a defined target state; regulatory and compliance risk identification; and a prioritised risk register with remediation options, cost estimates, and responsible owner assignments. The output is designed to be presentation-ready for board and audit committee review.
• How is data centre migration managed to minimise downtime risk?
  Data centre migration risk is managed through rigorous pre-migration preparation, not optimism. Our approach begins with a complete application dependency map — understanding what connects to what before a single server is moved. From there, we develop a wave plan based on dependency and business criticality, build cutover runbooks with hour-by-hour execution steps and defined go/no-go criteria, test rollback procedures before the migration window opens, and validate the target environment fully before cutover begins. Each wave is a controlled, documented event — not an improvised move.

Cloud Services — Implementation & Execution

• Which cloud platforms do you work with?
  We work across all three major hyperscalers — Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). We also support multi-cloud and hybrid cloud architectures where workloads span more than one platform or where on-premise infrastructure connects to cloud environments. Platform recommendations are made based on workload requirements, existing technology investments, and compliance obligations — not vendor preference.
• What is the difference between cloud migration and cloud transformation?
  Cloud migration is the process of moving existing workloads, applications, and data from their current location — on-premise, hosted, or another cloud — to a target cloud platform. The architecture is largely preserved; the location changes. Cloud transformation is a broader engagement that includes modernising how applications are built, deployed, and operated as part of or following the migration — containerisation, microservices, serverless, CI/CD pipeline adoption, and DevSecOps practices. Migration is the move. Transformation is what you do once you have moved to realise the full operational and commercial potential of the cloud.
• How long does a cloud migration typically take?
  Timeline depends on the number and complexity of workloads, the migration strategy applied to each (rehost, replatform, or refactor), and the compliance requirements of the environment. A focused migration of 20 to 50 workloads with clear dependencies typically takes eight to sixteen weeks end-to-end — from discovery through to post-migration stabilisation. Larger enterprise cloud migration engagements covering hundreds of workloads may take six to eighteen months. We provide a validated timeline as part of every scoping engagement — based on your actual inventory.
• What security controls do you implement during a cloud deployment?
  Security is implemented during the build — not recommended after it. Every cloud environment we deploy includes a least-privilege IAM framework, network segmentation and security group configuration, encryption at rest and in transit for all data stores, centralised logging and monitoring, cloud-native threat detection integration (AWS Security Hub, Microsoft Defender for Cloud, GCP Security Command Center), and a documented security baseline aligned to CIS Benchmarks. For regulated environments, additional compliance controls are layered on top of this foundation.
• What happens after a cloud migration is complete?
  Every cloud migration engagement includes a structured 30-day hypercare period post-migration — during which our team actively monitors the environment, resolves stabilisation issues, and ensures your team has the operational confidence to manage the new environment independently. We also deliver a complete documentation package, operational runbooks, and a knowledge transfer programme as standard. Beyond hypercare, ongoing managed cloud operations is available as a separate managed service engagement.
• Can you migrate our environment from one cloud provider to another — not just from on-premise?
  Yes. Cloud-to-cloud migrations — from AWS to Azure, GCP to AWS, or any other combination — follow the same structured methodology as on-premise migrations, with the additional consideration of data egress costs, service mapping between platforms, and identity federation between cloud environments. We assess the complexity, cost, and timeline of a cloud-to-cloud migration as part of the initial scoping engagement.

Pricing & Engagement

We are often asked why we do not publish fixed pricing. The honest answer: because doing so would mean overcharging lean environments and under-protecting complex ones. Every scope we build is a reflection of what your environment actually needs — not a standard product packaged for simplicity.

• Why do you not publish pricing for your services?
  Because the cost of any managed security, infrastructure, or cloud service is determined by what your environment actually needs — its size, complexity, compliance requirements, existing tooling, and required SLA windows. A price list that covers all scenarios is either so broad it is meaningless or so simplified it misleads. What we do instead is scope every engagement individually, explain every cost driver, and provide a fixed-price proposal that you can take to your finance team with confidence — before any commitment is made.
• What factors determine the cost of a managed security services engagement?
  The primary cost drivers are: the number of assets and log sources to be monitored, the service tier selected (SOC-only, full MSSP, or MSSP with additional services), the response SLA required, the compliance frameworks to be supported, the condition and coverage of your existing tooling, and the contract duration. A 12-month engagement typically offers better unit economics than a month-to-month arrangement. All of these variables are discussed openly during our scoping session before any number is presented.
• How do you structure your proposals — fixed price, time-and-materials, or retainer?
  It depends on the service type. Managed services — MSSP, SOC, and NOC — are structured as fixed monthly retainers, giving you a predictable, budgetable cost with no end-of-month surprises. Project-based services — cloud migration, data centre design, and consultancy engagements — are scoped and priced on a fixed-price basis per engagement, covering all deliverables within the agreed scope. Time-and-materials arrangements are available for exploratory or undefined-scope work, but we find that properly scoped fixed-price engagements serve clients better in practice.
• Is there a minimum contract duration for managed services?
  Managed services engagements — MSSP, SOC as a Service, NOC as a Service — are typically structured with a minimum initial term, most commonly twelve months. This reflects the onboarding investment made at the start of an engagement: deploying tooling, building detection rules, baselining your environment, and training our analysts on your specific topology. These are not activities that amortise well across a one-month engagement. Longer initial terms also typically offer better pricing efficiency. Specific terms are discussed and agreed during the proposal process.
• Are there any hidden costs we should be aware of?
  No. Our proposals are itemised — every cost line is explained and nothing is bundled in a way that obscures what you are paying for. The most common "surprise" cost in managed services engagements with other providers is additional charges for incident response beyond a certain volume, or for compliance reporting that was described as included but invoiced separately. We address these explicitly in every proposal: what is included, what is excluded, and under what circumstances additional investment would be required.
• Can we start with one service and add more later?
  Yes. Many organisations begin with a single service — most commonly SOC as a Service or MSSP — and add NOC, cloud, or data centre services as the relationship develops and their requirements evolve. Each service can be scoped and priced independently, and our managed services platform is designed to integrate across service lines rather than operating as separate silos. You are not locked into a specific service bundle from the outset.

Getting Started

• What does the process look like from first contact to active service?
  The typical journey from first conversation to live service delivery follows five steps: an initial scoping conversation (30 to 45 minutes) where we understand your environment and requirements; a proposal delivered within 48 business hours covering scope, deliverables, SLAs, and investment; a proposal walkthrough session where we answer every question before you decide; contract and onboarding — which for managed services includes a structured intake process covering asset discovery, tooling deployment, and baseline configuration; and go-live, when active monitoring or service delivery begins. For managed security services, go-live typically occurs within 21 business days of contract signature.
• What do you need from us during the onboarding process?
  Onboarding requirements vary by service, but typically include: access to your network and systems for monitoring agent or connector deployment; current network diagrams, asset inventory, and existing security documentation where available; introduction to key technical contacts and escalation stakeholders; and agreement on communication protocols, escalation paths, and change management procedures. All of this is documented in a shared Onboarding Workbook so nothing is applied without your awareness.
• How disruptive is the onboarding process to our existing operations?
  For managed security services, onboarding is designed to be non-disruptive. Monitoring agents and SIEM connectors are typically deployed without system restarts or maintenance windows. Where firewall rules or access changes are required, they are coordinated with your IT team through your standard change management process. The onboarding period — usually 10 to 21 days — involves light-touch coordination rather than heavy operational involvement.
• What if we already have a security or infrastructure provider — can we switch to you?
  Yes. Transitions from existing managed service providers are a structured part of our onboarding capability. We perform a transition assessment to understand what the current provider manages, what documentation exists, and what gaps must be addressed. The transition timeline is managed carefully to ensure there is no gap in coverage between providers.
• What reporting will we receive and how often?
  Reporting is defined per engagement but generally includes real-time dashboard access for authorised stakeholders, weekly status summaries during the first 90 days, monthly operational reports covering threat activity and SLA performance, and quarterly strategic review meetings with senior representatives. Executive-level reporting for board or audit committee presentations is also available.
• What happens if we are not satisfied with the service?
  Our service agreements include clearly defined performance standards with monthly SLA reporting. If targets are not met, the contract specifies remedies such as service credits and a formal remediation plan. Each engagement also includes quarterly review sessions with senior representation to address concerns before they escalate.
• What is the difference between cloud migration and cloud transformation?
  Cloud migration refers to moving existing workloads, applications, and data from on-premise or hosted environments to a cloud platform while preserving the existing architecture. Cloud transformation is broader — modernising applications using containerisation, microservices, serverless architecture, and DevOps practices. Migration is the move; transformation is the upgrade that unlocks the full value of cloud computing.

Every Engagement Starts With a Conversation. Ask Us Anything — Directly.

This page covers the questions that arise most frequently in pre-engagement conversations. But every organisation is different — and the question that matters most to your situation might not be the one that appears most often in ours.

Our team is accessible for direct questions. No contact form that routes to a sales sequence. No auto-responder acknowledging your inquiry. A direct conversation with the people who will actually scope and deliver your engagement.

• ✔ Ask about a specific service — we will explain exactly what it includes for your environment
• ✔ Ask about our team's certifications and experience in your industry
• ✔ Ask for a free assessment before committing to anything
• ✔ Ask for references from comparable organisations — we will be transparent about what we can share

Ready to Go Deeper on a Specific Service?

Each service page covers implementation methodology, what is included, how pricing is structured, and detailed FAQs specific to that service. Use these links to continue your evaluation: