Data Security Policy and Standards

ThreatWatch data security policy addresses the following core principles.




ThreatWatch services are designed to collect, store or process data that is absolutely essential for offering features and services to its consumers. ThreatWatch does not collect any user identifiable data other than what is essential for users to identify themselves and secure their own access for the purpose of authentication. Currently this is limited to the email address of the user who has signed up for the service.

The use of email address is exclusively used for verification and validation of user access. If users decide to use alerts or notifications, registered email addresses is used for delivery of email notifications.

Asset meta data is collected to identify vulnerabilities that are relevant to the assets. This information is limited to operating system details ( if applicable) and names and versions of installed software libraries.

ThreatWatch does not require nor does it store credentials for any service accounts that may be used for asset discovery.


ThreatWatch data retention policy is completely governed by user control and all data collected is as per the privacy policy of the company that can be found here.

ThreatWatch allows creation of policies for data purge that purges all data that is in scope of the defined policy. We strongly believe that it is our obligation to provide full and direct control to users for deciding data retention duration. These policies can be automated at set schedules as defined by organizational policies or requirements due to industry regulations. ( eg CCPA / GDPR )


Data Access and Management covers security controls that are necessary to protect confidentiality, integrity and availability of data , both when data is at rest or in transit.

Access to data is only available via the ThreatWatch I3 web console. The web console follows the OWASP ASVS ( Application Security Verification Standard ). The following functional requirements are implemented and monitored,

V1 : Architecture , Design and Threat Modeling

V2: Authentication Verification

V3: Session Management

V4: Access Control

V5: Validation , Sanitization and Encoding Verification

V6: Stored Cryptography Verification

V7: Error Handling and Logging

V8: Data Protection Verification

V9: Communication Verification

V10: Malicious Code Verification

V11: Business Logic Verification

V12: File and Resource Verification

V13: API and Web Service Verification

V14: Configuration Verification

User Access and Roles

  • Consumer Access
    • ThreatWatch SaaS user accounts are individual user accounts with identical privileges and silo’ed access to the assets created by the user. Asset’s are not shared between users.
    • ThreatWatch Enterprise allows great deal of flexibility for access management. All ThreatWatch Enterprise deployments come bundled with SSO support. An explicit allow list can be configured that provides an additional layer of security to gate access to the instance.
    • ThreatWatch Enterprise supports three user roles,
      • Admins – Full Access + Access to User and Org Management.
      • Regular Users – Full Access OR Tag Based Access
      • Discoverer – Access to discover assets OR Tag Based Access
  • Support / Troubleshooting Access
    • Temporary account provisioning for troubleshooting , periodic maintenance of customer instance or support activity is required. The activity of this account is monitored and does not have access to customer data.


Customer Instance Security ( aka ThreatWatch Enterprise )

  • Deployment is carried out via automated scripts and all deployments follow the CIS hardening standards. Additionally, the following controls are put in-place as best practices,
  • Access to root account is disabled.
  • Brute Force attacks for management access has DoS protections and lockouts.
  • Inter-service transport is strictly over HTTPS
  • Disk Level Encryption is enabled for all customer instances and database level encryption support can be turned on as per customer requests.
  • Other than port 443 ( https ) , no other ports access is required for data communication.
  • SSH port 22 is accessible from restricted servers strictly via certificate based authentication and only for the designated support account.
  • All communication is stateless and data is not cached in memory or any secondary storage.
  • All sensitive data is either hashed (SHA256) with salt (passwords) or secured via attribute level encryption (API keys).
  • API access requires both the API key ( no shared keys ) and a user handle associated with the account.


Reviewed : 10th Aug 2021