Security Policy

1. Scope and Purpose

This Security Policy articulates the comprehensive set of principles, frameworks, and operational protocols established by QSG TechLabs Pvt Ltd to govern the secure processing, transmission, and storage of data handled through its SaaS product, BriskBill, a robust cloud-based invoicing and billing platform. The policy serves as a foundational element in ensuring organizational resilience, client trust, and legal conformity.

• 1.1 Objective of the Policy
  • The primary aim of this Security Policy is to systematically safeguard all categories of information — including personal user data, enterprise client information, and financial transaction logs — from incidents of unauthorized access, data loss, data exfiltration, corruption, and service disruption.
  • This policy affirms BriskBill’s commitment to:
    • Upholding confidentiality, by restricting access only to authorized personnel;
    • Preserving integrity, by ensuring information is accurate, consistent, and protected from tampering;
    • Guaranteeing availability, by ensuring that systems remain operational and accessible to users when needed;
    • Complying with legal, regulatory, and contractual obligations, particularly within the purview of Indian Information Technology laws, including privacy and cybersecurity statutes;
    • Enhancing and maintaining user confidence through transparent, effective, and verifiable data protection measures;
    • Preparing against both external cybersecurity threats (e.g., DDoS attacks, phishing, malware) and internal threats (e.g., misconfigured permissions, insider misuse).
• 1.2 Applicability
  • This policy shall apply uniformly to all individuals and entities interacting with BriskBill’s systems, including but not limited to:
    • Platform users who are registered as administrators, staff, or operators managing business operations;
    • Employees, interns, or contractual personnel under direct engagement with QSG TechLabs Pvt Ltd;
    • External vendors, service providers, auditors, or support technicians who are granted access to any part of the BriskBill system or infrastructure.
  • The policy governs all data processed through the following mediums:
    • BriskBill’s web application hosted on secure cloud environments;
    • Mobile interfaces designed for operational flexibility;
    • APIs or third-party integrations that facilitate extended service functionalities;
    • Backend or administrative interfaces used by support or compliance teams to resolve user issues or manage platform operations.
• 1.3 Legal and Regulatory Alignment
  • This policy is designed in alignment with and pursuant to the following applicable standards and legal frameworks:
    • The Information Technology Act, 2000 (India), particularly Sections 43A and 72A relating to data protection and penalties for breaches;
    • The SPDI Rules, 2011, which lay down obligations relating to the collection, processing, and protection of Sensitive Personal Data or Information (SPDI);
    • Global and industry-recognized standards such as:
      • ISO/IEC 27001 for Information Security Management Systems;
      • OWASP Top 10 as a benchmark for identifying common vulnerabilities;
      • PCI-DSS, wherever applicable to payment or card-processing components.
• 1.4 Policy Ownership and Oversight
  • This Security Policy is officially owned, governed, and maintained by the Security & Compliance Team at QSG TechLabs Pvt Ltd, which is responsible for policy enforcement, training, and periodic audits.
  • The policy is reviewed at least once annually, and may be revised earlier under the following circumstances:
    • Discovery or emergence of novel or escalated cyber threats or data security vulnerabilities;
    • Infrastructure overhauls or major modifications in the application’s architecture or data flow mechanisms;
    • Amendments in applicable data protection or IT-related laws, or recommendations from independent audits or regulatory agencies.

2. Data Classification and Handling

This section outlines BriskBill’s systematic approach to classifying, storing, accessing, and managing different types of data based on their sensitivity, criticality, and legal/regulatory implications. Classification enables the application of differentiated security controls to mitigate risks and ensure lawful, ethical, and secure handling of all data.

• 2.1 Data Types Collected and Managed
  BriskBill collects and processes the following categories of data from its users, clients, and internal systems to deliver its services effectively:
  • User Data: Includes personally identifiable information (PII) such as names, email addresses, registered phone numbers (optional), business identifiers, IP addresses, encrypted passwords, and user preferences.
  • Client Data: Information uploaded or managed by users regarding their own customers, such as full names, contact information, billing addresses, and GST or tax IDs (where applicable).
  • Billing and Financial Data: Subscription plans, invoice histories, payment references, UPI IDs (without full financial instrument details), applicable taxes, and account balances.
  • Banking Details: Admin account numbers, bank names, and account holder names stored securely in encrypted format; BriskBill does not store card numbers, CVVs, or PINs.
  • Operational Metadata: Includes system logs, usage statistics, activity timestamps, support tickets, and audit trails for compliance and performance analysis.
• 2.2 Data Classification Levels
  All data managed through BriskBill is categorized into the following sensitivity tiers to enable tailored handling, access, and protection measures:
  • Level 1 – Public: Non-sensitive content that can be disclosed without risk, such as marketing brochures, pricing FAQs, and publicly published blogs or knowledge base articles.
  • Level 2 – Internal Use: Information not meant for public release but not inherently sensitive, such as internal release notes, support tickets, and anonymized analytics.
  • Level 3 – Confidential: Data whose unauthorized access may result in moderate to high harm. Includes user credentials (in hashed format), client data, and transaction logs.
  • Level 4 – Sensitive Confidential: High-risk data such as bank account details, administrative access tokens, internal encryption keys (in managed vaults), and financial audit records.
• 2.3 Handling Guidelines by Classification
  • All Confidential and Sensitive Confidential data shall be:
    • Encrypted using TLS (for transit) and AES-256 (for storage) protocols;
    • Governed by Role-Based Access Controls (RBAC) to restrict access to users with legitimate need and approved roles;
    • Logged in system audits for every access, modification, or export event;
    • Stored only in secure, jurisdiction-compliant environments (such as AWS regions adhering to Indian data residency rules);
    • Backed up regularly and protected from loss, unauthorized replication, or external transmission without formal authorization.
  • Internal Use data must be:
    • Limited to internal operations teams with clear roles in engineering, support, or compliance;
    • Accessed only from secure, monitored networks using approved accounts;
    • Retained only as long as operationally necessary and subject to periodic review.
  • Public data shall be:
    • Carefully reviewed by authorized personnel before release to ensure no embedded sensitive metadata or links exist;
    • Hosted on servers that are logically segregated from core application databases to prevent unintended access or linkage.
• 2.4 User Data Responsibility
  BriskBill users (especially Admin accounts) are responsible for ensuring:
  • The data they upload complies with applicable data privacy regulations, including obtaining informed consent before collecting or sharing third-party personal data;
  • Data does not infringe on the intellectual property, privacy, or contractual rights of any party;
  • Sensitive data fields are used appropriately and only when necessary;
  • Platform settings related to visibility, sharing, and deletion are configured in accordance with internal policies or customer agreements.
• 2.5 Data Minimization
  BriskBill upholds the data minimization principle by:
  • Collecting only those data points that are strictly necessary for onboarding, billing, support, and compliance;
  • Never storing full credit/debit card numbers, CVV values, or UPI PINs, in compliance with RBI and PCI-DSS requirements;
  • Allowing users to edit, delete, or anonymize certain non-essential data fields to retain control over their own and their clients’ digital footprint.

3. Authentication and Access Control

To ensure that only legitimate, authorized individuals and systems interact with BriskBill’s sensitive data and administrative functions, a multi-tiered authentication and access control framework is implemented. This framework reduces the risk of unauthorized entry, protects user integrity, and ensures accountability at every access point across the platform.

• 3.1 User Authentication Mechanisms
  • All BriskBill users, including Admins and Staff, are required to authenticate via a secure login process that utilizes a registered email and password combination. The system enforces the following password policies:
    • Minimum length of 8 characters with at least one uppercase letter, one lowercase letter, one numeric digit, and one special character;
    • Passwords are validated for complexity and banned-password lists during creation or reset;
    • Credentials are never transmitted or stored in plaintext — instead, they are salted and hashed using strong cryptographic algorithms and managed securely via AWS Secrets Manager.
  • For enhanced account security, BriskBill supports and may enforce Two-Factor Authentication (2FA) for certain user roles, particularly:
    • Admin accounts managing financial or sensitive client data;
    • Any user with permission to integrate APIs or modify billing;
    • Higher-tier plans where added security features are contractually required by enterprise clients.
• 3.2 Role-Based Access Control (RBAC)
  • BriskBill enforces a strict Role-Based Access Control (RBAC) model, wherein every user is assigned specific permissions based on their role within the organization.
    • Admin Role: Full access to customer billing, invoice generation, user management, subscription settings, and platform configurations.
    • Staff Role: Limited access to operational features as explicitly assigned by the admin, including optional restrictions on client visibility, report generation, and export functions.
  • Staff accounts by default are restricted from:
    • Changing or cancelling subscription plans;
    • Accessing or altering payment gateway integrations, payout information, or master financial records;
    • Viewing or downloading any bank-linked data unless explicitly allowed via permission toggles.
• 3.3 Session and Access Management
  • All user sessions are authenticated through time-bound tokens and secure HTTP-only cookies, providing session persistence without exposing credentials.
    • Session cookies are configured with Secure and SameSite flags to prevent cross-site scripting (XSS) or request forgery attacks.
    • BriskBill enforces automatic session timeouts after periods of inactivity, with configurable durations based on account type.
    • Users are prompted to re-authenticate on sensitive actions, such as exporting reports or modifying roles.
  • Concurrent session restrictions are enforced to prevent misuse of shared accounts. Any attempt to log in from multiple geographic locations or devices within a short span is flagged.
  • All session tokens are:
    • Immediately invalidated on logout, password reset, or administrative account disablement;
    • Monitored through backend logging to detect abnormal session behaviour or unauthorized retention.
• 3.4 Internal System Access
  • Only vetted and authorized personnel from QSG TechLabs Pvt Ltd are permitted to access the production infrastructure and databases supporting BriskBill. These include developers, DevOps engineers, and compliance team members with operational responsibilities.
  • Internal administrative access is governed by strict protocols:
    • SSH Key-Based Authentication is mandatory; password-based login is entirely disabled on production systems;
    • All sessions are logged, monitored, and where necessary, screen-recorded to capture privileged operations;
    • In specific high-risk operations (e.g., database patching or encryption key rotation), Just-in-Time (JIT) Access is granted for a limited duration, subject to managerial approval.
• 3.5 Access Reviews and Audits
  • The Security & Compliance Team performs quarterly audits of all user access rights, permissions, and roles across the platform. These reviews are also triggered ad-hoc during personnel changes or security incidents.
  • Any user account or internal role identified to have outdated, excessive, or anomalous access is either updated or revoked within 24 hours, with documented justification.
  • All access-related activities, including logins, failed attempts, role changes, and API key usage, are:
    • Captured in tamper-proof audit logs;
    • Retained securely for at least 180 days;
    • Available for review during security audits, compliance verifications, or breach investigations.

4. Data Encryption and Storage Practices

BriskBill enforces advanced encryption standards and secure storage methodologies to preserve the confidentiality, integrity, and availability of all data within its system. These measures ensure that data, whether in transit or at rest, remains protected against unauthorized access, manipulation, leakage, or loss — meeting both industry benchmarks and legal obligations under Indian IT law and global data security protocols.

• 4.1 Encryption in Transit
  • All communication between users and BriskBill servers is encrypted using Transport Layer Security (TLS) v1.2 or higher, ensuring that no data is transmitted in cleartext over the internet.
  • This encryption applies uniformly across all interfaces and access points, including:
    • User interactions via web browsers or mobile apps;
    • Server-to-server calls through public and private APIs;
    • Background jobs or third-party webhook deliveries that trigger data synchronization or notifications.
  • SSL certificates are renewed automatically and continuously monitored for expiry or tampering using Certificate Transparency logs and alerts.
• 4.2 Encryption at Rest
  • BriskBill stores all persistent data in encrypted form within Amazon Web Services (AWS) infrastructure, using AES-256 encryption, which is an industry standard for secure data at rest.
  • The following categories of data are encrypted at rest:
    • User profile data including names, email addresses, contact numbers;
    • Customer data such as invoice records, billing addresses, and transaction metadata;
    • Application settings, audit trails, and logs;
    • System backups and disaster recovery snapshots.
  • Database encryption is managed through AWS-native mechanisms with built-in key management and access control enforcement.
• 4.3 Password and Credential Handling
  • BriskBill follows stringent practices for credential security. User passwords are:
    • Not stored in plaintext under any circumstance;
    • Salted and hashed using secure algorithms such as bcrypt or PBKDF2, which provide resistance against brute force and rainbow table attacks;
    • Never transmitted in URLs, query strings, or logs.
  • Administrative or integration credentials are:
    • Stored securely in AWS Secrets Manager or equivalent vaulting tools;
    • Subject to strict access controls and audit logs;
    • Automatically rotated where possible (e.g., API keys, webhook tokens).
  • Temporary access credentials such as password reset tokens are:
    • Valid only for a limited time window (typically 30–60 minutes);
    • Deactivated immediately upon use or expiration;
    • Cryptographically generated to prevent guessability.
• 4.4 Secure Key Management
  • All cryptographic keys used for encryption and decryption are managed in accordance with secure key lifecycle management policies, including generation, distribution, rotation, archival, and destruction.
  • Keys are:
    • Stored in AWS Key Management Service (KMS) with strong access policies;
    • Automatically rotated at fixed intervals or upon compromise;
    • Not exposed to developers, third-party vendors, or application runtime unless specifically approved with limited scope and time.
  • Key access logs are reviewed periodically to detect misuse or anomalies.
• 4.5 Data Segregation and Logical Isolation
  • BriskBill operates on a multi-tenant architecture and enforces logical isolation of customer data at both the application and database levels. This ensures one user or organization cannot access another’s data, even if hosted on the same physical infrastructure.
  • Database row-level security and tenant ID scoping are embedded into every major query and transaction call, preventing cross-account access.
  • Additional safeguards include:
    • Segregated access tokens per organization;
    • Database schemas configured to separate high-risk modules;
    • Firewall rules and VPC settings that isolate back-end services from public-facing resources.

5. Infrastructure and Hosting Security

BriskBill is deployed in a secure, high-availability cloud environment designed for resilience, scalability, and compliance with international standards. The underlying infrastructure leverages Amazon Web Services (AWS), which provides robust physical, network, and operational safeguards. This section outlines the specific architectural and technical measures used to protect BriskBill’s core infrastructure from breaches, misconfigurations, and physical threats.

• 5.1 Cloud Hosting Environment
  • BriskBill is hosted exclusively within AWS data centers, currently located in the United States and compliant with applicable security certifications and audit standards, including:
    • ISO/IEC 27001 for Information Security Management Systems;
    • SOC 1, SOC 2, and SOC 3 reports validating service controls;
    • PCI-DSS for financial transaction safety, where applicable.
  • These data centres implement a layered physical security model, including:
    • 24/7 armed security personnel, CCTV surveillance, and motion-detection systems;
    • Controlled biometric and RFID card-based access to server rooms;
    • Multi-zoned architecture with fire suppression, seismic bracing, and climate control;
    • Redundant power and diesel generator backups to ensure uninterrupted uptime.
• 5.2 Network Security
  • BriskBill’s infrastructure is deployed within Virtual Private Clouds (VPCs), isolating environments and enforcing secure routing rules.
  • Network-level protection includes:
    • Security groups configured with least-permissive rules (deny by default);
    • Strict ingress controls allowing traffic only over essential ports (e.g., port 443 for HTTPS);
    • Internal services accessible only through private subnets and bastion hosts.
  • A layered firewall architecture ensures both perimeter and microsegment security, complemented by AWS Shield for protection against DDoS attacks.
• 5.3 Server Configuration and Hardening
  • All servers provisioned by BriskBill are based on hardened Amazon Machine Images (AMIs), which undergo continuous evaluation and patching. Each server is deployed with:
    • Minimal installed software packages to reduce the attack surface;
    • Deactivated unused ports and services;
    • Up-to-date kernel and security patches applied through automated patching tools.
  • Administrative access to production servers is limited and governed by:
    • SSH key-based authentication (no password login allowed);
    • Session recording for privileged actions;
    • Just-in-Time (JIT) access workflows for emergency interventions, with logs and approval chains.
• 5.4 Database Security
  • BriskBill uses AWS-managed PostgreSQL services for storing structured data, with built-in resilience and encryption. Database-level protections include:
    • Encryption at rest and in transit using AWS KMS;
    • Daily automated snapshots and multi-AZ deployments for durability;
    • Point-in-Time Recovery (PITR) enabled for restoration up to the last second before any failure.
  • Access to databases is tightly controlled:
    • Only application-level service accounts and limited internal personnel are granted access, following RBAC principles;
    • Production and development environments are fully segregated, preventing data leakage from testing or staging scenarios;
    • SQL-level access requires elevated privilege approvals and is audited for traceability.
• 5.5 Availability and Resilience
  • BriskBill employs AWS-native high-availability features to ensure continued service, including:
    • Auto Scaling Groups to handle sudden traffic surges;
    • Elastic Load Balancers (ELBs) to distribute traffic evenly across healthy servers;
    • Multi-AZ deployments to guard against availability zone failures.
  • Infrastructure is monitored continuously with alerts configured for:
    • Unexpected downtime;
    • CPU/memory overloads;
    • Latency spikes or service degradation.
  • In the event of a regional AWS outage, BriskBill’s disaster recovery plan allows for migration of services to alternative AWS regions or zones, minimizing impact and ensuring business continuity.

6. Backup and Disaster Recovery

BriskBill employs a robust and automated Backup and Disaster Recovery (BDR) framework to maintain service continuity and ensure data survivability in the face of hardware failure, cyberattacks, natural disasters, or other operational crises. The strategy combines encrypted backups, geo-redundant storage, recovery simulations, and incident escalation protocols to ensure customer data is never permanently lost or irrecoverable.

• 6.1 Backup Strategy
  • BriskBill performs automated daily backups of all critical systems and user data, including:
    • Business account settings, user profiles, and access configurations;
    • Invoice records, payment histories, and client contact data;
    • Internal logs, support records, and system-level metadata necessary for restoration.
  • Backup operations are orchestrated through AWS-native tools with:
    • Automated scheduling to minimize manual error;
    • Cross-region replication for geographical redundancy;
    • Differentiated backups (full, incremental, and differential) to optimize storage and restore times.
  • Backup files are:
    • Encrypted using AES-256 before being transmitted to Amazon S3 buckets;
    • Versioned, allowing access to previous states in case of accidental deletion or data corruption;
    • Retained for a minimum of 30 days, and longer where required by legal, contractual, or audit requirements.
• 6.2 Backup Testing and Verification
  • BriskBill does not assume backups are successful unless verified. Integrity is checked using:
    • Automated checksum validation after each backup cycle;
    • Routine testing scripts that simulate partial and full recovery operations in isolated environments.
  • Quarterly disaster simulation exercises are conducted to:
    • Ensure that the restoration process works as intended;
    • Train staff in rapid response protocols;
    • Identify bottlenecks or inconsistencies in backup workflows before an actual incident occurs.
• 6.3 Disaster Recovery (DR) Planning
  • BriskBill maintains a documented and regularly updated Disaster Recovery Plan (DRP) that outlines the organizational response to events such as major data centre failures, ransomware attacks, or system corruption. The DRP includes:
    • Clear incident classification levels based on severity and impact;
    • Assigned roles and responsibilities for engineering, compliance, and support teams;
    • Defined communication protocols, including internal escalation and external client communication;
    • A fallback infrastructure plan allowing service migration to alternate cloud regions or instances.
  • The DRP is reviewed annually or after major changes in system architecture, regulatory requirements, or following any real incident where recovery was triggered.
• 6.4 Recovery Point and Time Objectives
  • BriskBill adheres to strict disaster recovery targets to minimize data loss and downtime:
    • Recovery Point Objective (RPO): ≤ 24 hours;
    • Recovery Time Objective (RTO): ≤ 4 hours.
  • These targets are monitored using SLA dashboards and reported to management for compliance review.
• 6.5 Data Restoration Requests
  • If a user experiences data loss due to accidental deletion, misconfiguration, or a verified security incident, they may submit a formal Data Restoration Request via the BriskBill support portal.
  • Restoration timelines:
    • Most requests are fulfilled within 48 business hours, subject to the complexity and availability of backups;
    • BriskBill support will communicate clearly about eligibility, cost (if any), and success likelihood before proceeding;
    • Any restoration may be partial or scoped to a specific data module (e.g., invoices, settings).

7. Monitoring, Incident Response, and Breach Notification

BriskBill employs a vigilant and layered monitoring infrastructure to detect and respond to security threats in real-time. A formal incident response mechanism is in place to assess, contain, and mitigate any threats or breaches affecting system integrity or user data. Timely user notification and compliance with Indian IT laws are central to BriskBill’s breach management approach.

• 7.1 System and Access Monitoring
  • BriskBill implements continuous monitoring across its entire cloud infrastructure and application stack, using a combination of real-time analytics, anomaly detection, and rule-based alerts. Monitored assets include:
    • Application logs tracking user actions, API responses, and exception events;
    • Database logs capturing query patterns, permission escalations, and data access events;
    • Admin and system access logs, especially for privileged accounts;
    • Network traffic for identifying suspicious volumes, geolocation anomalies, or brute-force attempts.
  • All logs are:
    • Time-synchronized across systems to maintain forensic integrity;
    • Stored securely and retained for a minimum of 90 days;
    • Reviewed by the security team on a periodic basis and flagged using thresholds or heuristics defined in correlation rules.
• 7.2 Intrusion Detection and Prevention
  • BriskBill’s infrastructure is integrated with automated Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) to detect:
    • Repeated failed login attempts that indicate brute-force or credential stuffing attacks;
    • Data exfiltration attempts through abnormal API export activity;
    • Access patterns from known blacklisted IPs or suspicious geographies;
    • Abuse of privileges by internal or external actors.
  • Upon detection of a threat indicator, automated and manual remediation steps include:
    • Temporary or permanent account lockdown;
    • Forced password resets for all affected accounts or domains;
    • Generation of detailed internal incident reports for escalation and action by the security response team.
• 7.3 Security Incident Response Plan
  • BriskBill operates under a formalized Security Incident Response Plan (SIRP), which defines step-by-step actions to take when security events occur, including:
    • Incident categorization based on scope and potential business or user impact;
    • An escalation matrix assigning responsibility for triage, containment, remediation, and communication;
    • Coordination with legal and compliance teams for sensitive or regulated incidents;
    • Templates and SOPs for forensic evidence collection, root cause analysis, and post-mortem documentation.
  • Security response drills are conducted semi-annually to ensure readiness of the technical and operations teams. Simulations include scenarios such as API abuse, database tampering, insider privilege abuse, and ransomware response.
• 7.4 Breach Containment and Mitigation
  • In the event of a confirmed data breach, BriskBill will execute containment protocols that include:
    • Immediate isolation of affected systems or users;
    • Revocation of access tokens, credentials, or API keys suspected of compromise;
    • Rollback to last clean backup, where data integrity is compromised;
    • Disabling compromised integrations or endpoints until resolution.
  • If the breach involves high-risk or cross-platform exposure, BriskBill may:
    • Engage third-party cybersecurity firms to assist in forensic analysis;
    • Seek legal counsel on disclosure obligations, contract violations, or regulatory implications;
    • Inform impacted vendors or partners as per contractual data sharing terms.
• 7.5 User Notification
  • In compliance with Section 72A of the Information Technology Act, 2000, BriskBill is committed to informing users within 72 hours if a data breach is confirmed and:
    • Involves their personally identifiable information (PII) or business-critical data;
    • Is likely to result in financial harm, account takeover, or trust impact.
  • Notification channels include:
    • Email alerts to account holders and Admins;
    • In-app banners or messages to display status and remediation steps;
    • If required by law, filing of breach reports with CERT-In (Indian Computer Emergency Response Team) or other competent authorities.
  • User notification will include:
    • A summary of the breach and affected systems or data;
    • Timeline of events and actions taken;
    • Recommendations for user-side actions (e.g., password changes, monitoring for phishing);
    • Contact details for further queries or support.

8. Employee Access and Confidentiality Controls

BriskBill enforces strict internal governance measures to ensure that employees and contractors of QSG TechLabs Pvt Ltd access production systems and customer data only when absolutely necessary. These controls are essential to preventing insider threats, enforcing accountability, and protecting sensitive user information from unintentional or malicious misuse.

• 8.1 Principle of Least Privilege
  • All employee access to sensitive systems, production databases, user environments, and configuration panels follows the Principle of Least Privilege (PoLP). This means:
    • Access is granted only to the minimum resources required for a specific role or task;
    • No employee is granted default access to critical systems without formal approval, regardless of seniority;
    • Access rights are reviewed and revoked immediately when no longer needed (e.g., post-project or transfer of role).
  • Critical infrastructure access (such as servers, CI/CD pipelines, or AWS accounts) is limited to select engineering or DevOps roles, with scope-limited credentials and audit trail requirements.
• 8.2 Access Authorization and Logging
  • All employee access to cloud infrastructure, production systems, admin dashboards, or security tools is:
    • Pre-approved by a designated team lead or security officer;
    • Provisioned through centralized access management platforms, ensuring traceability of every grant or revocation;
    • Protected with multi-factor authentication (MFA), ensuring that stolen credentials alone cannot result in unauthorized access.
  • Every action performed by internal users with elevated permissions is:
    • Logged with time stamps and user IDs;
    • Stored in secure audit logs retained for at least 180 days;
    • Periodically reviewed for unusual patterns, such as off-hours access, abnormal data queries, or role modifications.
• 8.3 Onboarding and Offboarding Processes
  • During onboarding, every new employee or contractor is required to undergo:
    • Security awareness training covering BriskBill’s security policies, data privacy obligations, and access hygiene protocols;
    • Signing of confidentiality, intellectual property, and non-disclosure agreements (see Section 8.4);
    • Guided induction into tools or environments relevant to their roles, with tiered access provisioning.
  • On offboarding (voluntary or otherwise), the following actions are executed within 12 hours:
    • Immediate revocation of all credentials, including VPNs, cloud platforms, internal portals, and Git repositories;
    • Collection or disabling of issued assets, such as laptops, USB tokens, or mobile devices with stored credentials;
    • Removal from internal collaboration tools (e.g., email, Slack, Jira) following a pre-defined checklist approved by HR and IT.
• 8.4 Confidentiality Agreements
  • Every employee, contractor, or intern granted access to BriskBill systems or data is required to sign a Confidentiality and Non-Disclosure Agreement (NDA). These agreements:
    • Clearly define the scope of protected information, including user data, source code, business strategies, and infrastructure details;
    • Prohibit data sharing, external storage, or unauthorized reuse both during and after the term of employment;
    • Establish legal consequences for breach, including potential financial penalties, civil liability, or criminal prosecution under applicable laws.
  • These agreements remain enforceable even after separation, and compliance is monitored by the Legal and Compliance team.
• 8.5 Insider Threat Management
  • BriskBill proactively mitigates the risk of internal abuse or negligence through an Insider Threat Program, which includes:
    • Regular audit trail reviews to detect unusual patterns, such as mass exports or repeated access to the same record;
    • Behaviour-based anomaly detection powered by monitoring tools to flag activities outside normal work behaviour;
    • Access analytics dashboards that highlight high-risk roles, inactive accounts with elevated permissions, and unusual system interactions.
  • Any case of suspected insider abuse or policy violation is:
    • Investigated discreetly by a cross-functional team (security, legal, and HR);
    • Documented and, if necessary, escalated to senior leadership or law enforcement based on severity;
    • Used as a case study (anonymized) for refining internal access control policies and awareness training.

9. Third-Party and Vendor Risk Management

BriskBill operates within a technology ecosystem that relies on selected third-party services for critical functions such as payment processing, infrastructure hosting, analytics, email delivery, and technical support. While these integrations offer scalability and efficiency, they also introduce potential security and compliance risks. This policy ensures that all third-party engagements are evaluated, controlled, and monitored to safeguard user data and uphold legal obligations.

• 9.1 Definition of Third Parties
  A third party, for the purpose of this policy, refers to any external individual, company, platform, tool, or service provider that:
  • Is not directly employed by QSG TechLabs Pvt Ltd;
  • Has access to BriskBill’s systems, infrastructure, user data, or business processes;
  • Provides components essential to the functioning of the BriskBill application, such as:
    • Razorpay – for online payments and settlements;
    • Amazon Web Services (AWS) – for hosting infrastructure, databases, and backup services;
    • Email and SMS gateways – for transaction notifications;
    • Monitoring tools – for application uptime and performance logging.
• 9.2 Due Diligence Before Integration
  Before engaging any third-party vendor or service provider, BriskBill conducts a formal due diligence process that evaluates:
  • Security certifications such as ISO/IEC 27001, SOC 2 Type II, and PCI-DSS compliance;Data handling practices, including encryption, storage locations, and access control mechanisms;Breach history and incident response posture;SLA terms, including uptime guarantees, support availability, and response timelines;Jurisdictional compliance, especially if the vendor stores or processes data outside of India.
  No vendor is approved unless the Legal, Security, and Engineering teams jointly validate the risk profile and business need, and a formal agreement is executed.
• 9.3 Data Sharing Principles
  • BriskBill follows the principle of data minimization when interacting with third parties. Only the specific data necessary for fulfilling the defined function is shared. For example:
    • Razorpay receives only the necessary payment metadata and order references — never full user profiles or passwords;
    • Monitoring tools receive anonymized performance metrics and not actual invoice or transaction content.
  • All data transfers:
    • Are encrypted during transmission (TLS 1.2 or higher);
    • Use API tokens or service accounts with scoped permissions;
    • Are subject to rate limits and anomaly alerts to detect abusive behaviour.
• 9.4 Contracts and Security Agreements
  All third-party engagements are governed by legally binding documents, such as:
  • Master Service Agreements (MSAs) outlining commercial and service terms;Data Processing Addenda (DPAs) ensuring GDPR or SPDI compliance (if applicable);Confidentiality Clauses binding the vendor to protect BriskBill’s and users’ sensitive data.
  These contracts explicitly include:
  • Obligations for data confidentiality and non-disclosure;
  • Breach notification timelines, typically within 24–72 hours of detection;
  • Liability clauses for damages resulting from negligence, subprocessor misuse, or data exfiltration.
• 9.5 Ongoing Vendor Monitoring
  • Once integrated, vendors are subject to annual security reviews and may be audited for:
    • Ongoing compliance with security certifications;
    • Performance against SLA targets (e.g., uptime, latency);
    • Any vulnerabilities disclosed via public channels (e.g., CVEs, CERT alerts);
    • Legal or geopolitical risks arising from changes in regulation or vendor ownership.
  • If a vendor fails to meet BriskBill’s minimum security thresholds:
    • Access may be immediately restricted or suspended;
    • A remediation plan will be required before reinstatement;
    • A vendor exit strategy is initiated, including secure offboarding and data deletion from the vendor’s systems.
• 9.6 Incident Handling with Vendors
  • In the event of a vendor-originated security incident (e.g., payment gateway breach or email delivery compromise):
    • BriskBill will engage with the vendor’s security team to assess scope and initiate joint containment;
    • Users will be notified if their data is impacted (see Section 7.5);
    • Findings will be documented in BriskBill’s internal incident register, and the contract may be renegotiated or terminated based on the severity and response quality.

10. Secure Development and Change Management

BriskBill adheres to a disciplined, security-focused software development lifecycle (SSDLC) to ensure that the codebase and supporting infrastructure are resilient to vulnerabilities, compliant with industry standards, and auditable throughout their lifecycle. All new features, updates, bug fixes, and configuration changes are rigorously reviewed, tested, and tracked to prevent unauthorized alterations and reduce operational risk.

• 10.1 Secure Development Practices
  • BriskBill’s engineering team follows a formal SSDLC framework that embeds security at every stage, including:
    • Threat modelling during the design phase to anticipate potential misuse or exploitation vectors;
    • A mandatory security checklist for all feature releases that includes input validation, output encoding, and authentication requirements;
    • Use of both manual code reviews and automated vulnerability scans (e.g., SAST and dependency analysers) before pushing to production.
  • All developers receive regular training on:
    • Secure coding standards (e.g., OWASP Top 10, SANS CWE Top 25);
    • Common attack patterns such as SQL injection, Cross-Site Scripting (XSS), and SSRF;
    • Secure use of open-source components, including license reviews and supply chain awareness.
• 10.2 Version Control and Code Management
  • BriskBill’s codebase is managed using Git-based version control systems with the following practices:
    • Multi-branch architecture, allowing isolation of new features, hotfixes, and staging code from stable releases;
    • All critical modules have designated code owners whose approval is mandatory for changes;
    • Use of signed commits to ensure authorship verification and prevent tampering.
  • All merges into production branches are preceded by:
    • Peer review by at least one other developer;
    • Automated testing (unit, integration, security) passing all benchmarks;
    • Approval from a release manager or lead engineer, depending on the scope.
• 10.3 Change Management Workflow
  • Every code or infrastructure change is tracked via ticketing systems like Jira, with each change labelled and classified according to:
    • Risk level (low, moderate, high);
    • Affected environment (dev, staging, production);
    • Compliance and audit requirements, especially for data flows, authentication systems, and APIs.
  • Production deployments are allowed only after:
    • Staging environment tests have passed without regressions;
    • Rollback mechanisms have been confirmed (e.g., blue-green deployment or version pinning);
    • Formal sign-off from authorized approvers is recorded in the deployment logs.
• 10.4 Vulnerability Management
  • BriskBill implements both Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) to proactively identify and mitigate flaws.
    • SAST tools scan source code for unsafe constructs, secrets in code, or dependency vulnerabilities;
    • DAST tools simulate attack behaviour against live staging environments to uncover flaws not detectable by static analysis.
  • Identified vulnerabilities are classified and tracked. Remediation timelines are as follows:
    • Critical vulnerabilities (e.g., remote code execution, admin bypass): patched within 24 hours;
    • High-risk vulnerabilities (e.g., injection, data leaks): patched within 7 days;
    • Medium/low-risk vulnerabilities: documented and patched based on priority and impact analysis.
• 10.5 Deployment Controls
  • Production deployments are executed via Continuous Integration/Continuous Deployment (CI/CD) pipelines, which:
    • Allow deployment only by authorized DevOps personnel or release managers;
    • Maintain immutable deployment logs, mapping every deployment to a specific commit, user, and timestamp;
    • Use automated rollback triggers to restore the last working version if health checks fail post-deployment.
  • Configuration changes (e.g., environment variables, scaling rules) are subject to the same review and deployment process as code changes to prevent configuration drift or accidental exposure.

11. User Responsibilities and Best Practices

While BriskBill enforces robust internal controls and secure-by-design principles, the overall security posture of the platform also relies on responsible behaviour from its users. This section sets forth the roles, responsibilities, and expected best practices for end users, administrators, and staff to minimize risks, maintain system hygiene, and ensure compliance with data protection obligations.

• 11.1 Account Security
  • Users are solely responsible for protecting the confidentiality of their BriskBill account credentials, including:
    • The registered email ID and password used for login;
    • Any secondary authentication mechanisms such as Two-Factor Authentication (2FA) tokens or app-based verification codes.
  • Admin users must ensure that access to the platform is limited only to trusted individuals and that staff permissions are correctly scoped using the Role-Based Access Control (RBAC) system.
  • Sharing of login credentials is strictly prohibited, regardless of trust levels or team size. Any account found to be accessed from multiple unrelated devices or IPs may be flagged or temporarily suspended to protect platform integrity.
• 11.2 Password and Authentication Hygiene
  • Users must create passwords that meet strong complexity requirements, such as:
    • A minimum of 8–12 characters;
    • A mix of uppercase letters, lowercase letters, numbers, and symbols;
    • Avoidance of dictionary words, personal identifiers (like birthdays), or reused credentials from other services.
  • Passwords should be:
    • Updated at least once every 90 days or immediately if there is suspicion of compromise;
    • Stored in a secure password manager and never written down or sent via email or chat.
  • Users should enable Two-Factor Authentication (2FA) wherever supported. Admin users are strongly encouraged to mandate 2FA for all staff roles handling sensitive data or performing financial transactions.
• 11.3 Device and Network Usage
  • BriskBill should be accessed only from trusted, secure devices, including personal computers or company-managed laptops that are:
    • Regularly updated with the latest operating system and browser patches;
    • Protected by antivirus software and endpoint firewalls;
    • Not shared with others for casual or personal use.
  • Usage of public or unsecured Wi-Fi networks (e.g., cafes, airports) for accessing BriskBill is strongly discouraged, especially when handling client or financial data.
  • Devices used to access BriskBill should implement basic safeguards like:
    • Screen locks or automatic timeouts after inactivity;
    • Local encryption (e.g., BitLocker, FileVault);
    • Secure removal or logout from sessions after use.
• 11.4 Data Integrity and Compliance
  • Users are responsible for ensuring that any data entered into BriskBill:
    • Is lawfully collected and used with appropriate client or third-party consent;
    • Is accurate, up to date, and does not include sensitive personal data not required for invoicing or accounting purposes.
  • Users must not:
    • Upload content that is defamatory, obscene, threatening, fraudulent, or otherwise in violation of Indian laws;
    • Use BriskBill to transmit malware, unauthorized advertisements, or spam;
    • Attempt to reverse-engineer or tamper with BriskBill’s APIs or security controls.
  • Any regulated data (e.g., health records, banking credentials) should be handled in accordance with applicable laws and only stored on BriskBill if explicitly permitted by the platform’s Terms of Use and Privacy Policy.
• 11.5 Reporting Security Incidents
  • Users are obligated to report any suspected or confirmed security incident affecting their BriskBill account. These include but are not limited to:
    • Unauthorized logins or access attempts;
    • Unusual account activity (e.g., unapproved invoice generation or data export);
    • Suspected phishing emails or credential theft.
  • Reports should be made immediately via:
    • The support interface or ticketing system;
    • The security email contact listed in Section 12.3 of this policy.
  • BriskBill reserves the right to temporarily suspend accounts that are under investigation for potential compromise, misuse, or policy violation. Such action is purely precautionary and users will be informed of the next steps.

12. Policy Governance, Review, and Reporting Security Issues

This section defines the structure of ownership, review frequency, amendment responsibilities, and communication channels related to the Security Policy. It ensures that the policy remains current, legally compliant, and responsive to evolving technological, regulatory, and threat landscapes. It also empowers stakeholders — users, employees, and vendors — to raise security concerns in a structured and confidential manner.

• 12.1 Policy Ownership
  • This Security Policy is formally owned, maintained, and governed by the Security & Compliance Team of QSG TechLabs Pvt Ltd, which is responsible for:
    • Defining and interpreting security principles across the organization;
    • Ensuring implementation of the controls outlined herein;
    • Coordinating cross-departmental enforcement through engineering, legal, DevOps, and operations units.
  • Enforcement of this policy is not limited to the security team alone. All internal teams (including product, support, HR, and finance) must cooperate in implementing, reporting, and adhering to applicable sections.
• 12.2 Policy Review and Update Frequency
  • This policy is subject to semi-annual reviews to ensure alignment with:
    • Updates in applicable data privacy and cybersecurity laws (e.g., the Information Technology Act, SPDI Rules, GDPR if applicable);
    • Changes in BriskBill’s architecture, third-party dependencies, or risk assessments;
    • Findings or recommendations from internal audits, penetration tests, or security incidents.
  • In addition to scheduled reviews, the policy may be updated immediately in case of:
    • A newly identified threat or vulnerability that exposes gaps in existing practices;
    • Mergers, acquisitions, or major service expansions impacting infrastructure;
    • Changes in regulatory enforcement, such as directives from CERT-In or international data regulators.
  • All changes to the Security Policy:
    • Are version-controlled and dated with change logs;
    • Require approval from a senior compliance officer or director;
    • Are communicated to relevant internal and external stakeholders through documentation updates, email bulletins, or dashboard alerts.
• 12.3 Reporting Security Concerns
  • BriskBill encourages all users, employees, vendors, and third parties to report actual or suspected security vulnerabilities, privacy violations, or misuse. Reports may include:
    • Vulnerabilities discovered in the platform or integrations;
    • Inappropriate access attempts or data leakage incidents;
    • Weaknesses in encryption, authentication, or session management.
  • Reports can be submitted confidentially to:Security Contact
    QSG TechLabs Pvt Ltd
    S-505, World Trade Centre,
    Brigade Gateway Campus,
    Dr. Rajkumar Road, Malleswaram West,
    Bengaluru – 560055, Karnataka, India
    Email: it_admin@briskbill.com
  • BriskBill commits to:
    • Acknowledging reports within 3 business days of receipt;
    • Providing a resolution status update within 15 business days for verifiable concerns;
    • Offering credit or recognition (subject to legal approval) for responsible disclosure of genuine threats.
• 12.4 External Compliance and Audits
  • BriskBill may undergo periodic third-party audits and security assessments such as:
    • Penetration testing by external cybersecurity firms;
    • Data privacy audits for compliance with the SPDI Rules or sector-specific regulations;
    • Security reviews required by enterprise clients or government agencies.
  • Upon justified request (especially for enterprise customers under NDA), BriskBill may share:
    • Security whitepapers or summaries of recent audits;
    • Compliance certificates from service providers (e.g., AWS);
    • Proofs of adherence to security practices documented in this policy.
• 12.5 Acceptance of Security Policy
  • By accessing or using BriskBill, all users — including Admins, Staff, and third-party partners — are deemed to:
    • Have read and understood this Security Policy;
    • Agree to adhere to the controls, responsibilities, and protocols defined herein;
    • Acknowledge that continued use of BriskBill is subject to ongoing compliance with the latest version of this policy.
  • Any user found to be in material breach of this policy may be subject to:
    • Temporary or permanent suspension of platform access;
    • Legal liability if the breach results in data loss, fraud, or reputational harm;
    • Internal investigation and further action in accordance with applicable law or contract terms.