What security measures for Cloud Service Model & Data Hosting?
Section 1: Cloud Service Model & Data Hosting
1. What type of cloud service are you offering – Platform as a Service (PaaS) or Software as a Service (SaaS)?
SaaS
2. Can you confirm that all our customer transaction data will be stored only within our country?
Factech being a global company with clients across world. Data is stored as per client region or requirement.
3. Who will own the data once it is stored on your cloud platform?
You own all your data—always. Factech is only a custodian/processor and uses it solely to deliver the service.
Section 2: Legal & Compliance
4. Are you fully responsible for ensuring all software licenses you use are legal and properly managed?
Yes.
5. Do you have any official reports or certifications from independent third parties that show your service is secure and compliant?
Yes.
6. Can you share copies of recent audit or compliance reports with us?
Yes—under NDA. We provide recent third-party audit/compliance evidence via a secure, read-only portal.
Section 3: Security Measures
7. Do you have systems in place to protect against viruses, hacking, or other security threats?
Yes.
8. Can you explain how you protect the data and prevent unauthorized access?
-
Identity & access: MFA everywhere, least-privilege RBAC/ABAC, just-in-time privileged access (PAM), short sessions, IP allowlists.
-
Encryption: AES-256 at rest; TLS 1.2+/1.3 in transit;
-
Network: Private VPCs, subnet segmentation, SG/NACL firewalls, private endpoints, bastion-less access, WAF + API gateway, IDS/IPS, rate limiting + DDoS protections.
-
App & infra hardening: Secure SDLC, code review, SAST/DAST/SCA, secrets in a vault, container/image signing, minimal base images
-
Monitoring & response: Centralized tamper-evident audit logs, SIEM with anomaly alerts.
-
Data lifecycle: DLP controls, masking/tokenization in non-prod, retention schedules, verifiable deletion (incl. backups per purge cycles).
-
DR & availability: Encrypted backups, PITR, HA components, RPO/RTO defined and tested.
-
Standards: Controls mapped to ISO 27001:2022
9. What kind of encryption or password protection do you use to keep our data private and safe?
Encryption everywhere + strong password hygiene. AES-256 at rest, TLS 1.2/1.3 in transit, password hashing, MFA + passkeys.
10. Do you follow any known security standards or best practices (like ISO, NIST, etc.)?
ISO 27001:2022
Section 4: Disaster Recovery & Availability
11. Do you have a disaster recovery plan to make sure our data and services stay available if something goes wrong?
Yes.
12. How often do you test your disaster recovery plan? Can we see the results of the last test?
We test DR on a fixed cadence—quarterly tabletop, semi-annual partial failover, and a full-scale annual recovery (incl. backups + cross-region failover). Yes—the latest test report evidence can be shared under NDA.
13. How quickly can we expect service to be restored in case of an outage or problem?
P1 outage (service down): initial response ≤ 15 min, updates every 30 min, target restore ≤ 60 min (single-zone). If regional failover is required: restore ≤ 4 hrs.
Section 5: Service Commitments (SLAs)
14. What are your commitments regarding system uptime and availability?
Core app & APIs: 99.95% monthly uptime (≈ ≤22 min downtime in a 30-day month). Auth/SSO: 99.99%. Ancillary/reporting: 99.9%.
15. What is your usual response time when support is requested?
As per SLA, < 4 hours for critical, < 8 hrs for major and < 24 hours for minor issues. Refer SLA for details
16. Can you share your standard Service Level Agreement (SLA) with us?
Yes. It’s part of agreement signed.
Section 6: Risk Management
17. Has your service been reviewed by an internal security team before?
Yes.
18. What kind of risk management steps have been taken to protect our data and services?
We run a formal, continuously monitored risk program aligned to ISO 27001, VAPT. SIEM, DLP, IDS, Firewall, Password Policy, MDM, End point Security are in place
19. Are there any special agreements in place to protect us legally if something goes wrong with the service?
Yes. We offer strong legal protections in the MSA: indemnities (IP + data breach), SLA/service credits, DPA/privacy addendum, security incident obligations, and termination assistance/data export. Shared under NDA
Section 7: Access Control & Privacy
20. What steps do you take to make sure only authorized people can access our data?
-
Identity: MFA; WebAuthn/passkeys for admins; unique accounts (no shared creds).
-
Authorization: Least-privilege RBAC/ABAC; default-deny policies; scoped service accounts; short-lived API tokens; customer-defined roles.
-
Privileged access: JIT elevation via PAM with ticket/approval, time limits
-
Network guardrails: Private VPCs, security groups/NACLs, private endpoints/VPN, IP allowlists, no direct DB access.
-
Device/session: Device posture checks (disk encryption, patch level), idle timeouts, re-auth for sensitive actions, Secure/HttpOnly/SameSite cookies.
-
Monitoring & review: Tamper-evident audit logs for auth/admin/data export; SIEM alerts; quarterly access reviews
-
People & vendors: Background checks where lawful, least-privilege for staff/sub-processors, security training, contractual flow-downs
21. How do you make sure our data is separated from other customers’ data on your systems?
-
Tenant binding:
tenant_id
carried in auth token; every request and query is tenant-scoped by default (deny if missing/mismatch). -
App guardrails: Data access layer auto-injects tenant filters; no raw cross-tenant joins; unit/integration tests for isolation.
-
Database controls: RLS policies enforce
tenant_id
on every table; separate DB roles per service; no app superuser; schema-level privileges are least-privilege. -
Storage/search/queues: Per-tenant prefixes/indices/subjects with policies that block cross-tenant reads/writes.
-
Encryption: Per-tenant DEKs (wrapped by KMS) for at-rest data; optional field-level tokenization/masking for sensitive PII.
-
Admin access: JIT/PAM with explicit tenant selection, session recording; no global “read-all” views; all access logged with tenant tags and alerts on anomalies.
-
Backups/DR: Backups tagged by tenant and encrypted with that tenant’s key; restores scoped only to the requesting tenant.
-
Assurance: Periodic isolation tests, code scans, and external VAPT; findings tracked to closure.
22. Do you have a policy for protecting user privacy and handling personal information?
Yes.
Reference: