# Sprinto Docs Welcome to Sprinto Docs! Explore comprehensive and interactive documentation designed to help you navigate Sprinto's powerful compliance and security features. Whether you're getting started, managing your dashboard, or integrating frameworks, you'll find everything you need to make the most of Sprinto right here. ### What's New
Latest ReleasesSee what's new in Sprinto/pages/8qQaK9KmJNF4UymiRQnQ
Important UpdatesCritical changes that may impact you/pages/dqKxqRyVDKpQyXrXW53Q
Release ArchiveBrowse all past releases and updates./pages/1GwlgczkfmrcEZ7Jiv4H
### Start here
Cover image
Getting StartedDiscover how to set up Sprinto and kickstart your compliance journey!/files/Cwx0SyOLkqmvnPNIqh5k/pages/CyH2xJQs9yWJ1S8BYNav
IntegrationsConnect your tools and systems/files/o7vncsPmjG1fpThO4LWZ/pages/7aUFmnCMx9m4smGncsXL
AuditsStreamline your audit process and stay compliant with ease!/files/LrfVK1lapyjVssUmECva/pages/0V937QMoNNa6x3Vp9xrI
MonitoringTrack, manage and fix your workflow checks/files/KGE7hPz42htmTjay554h/pages/dlL05qSvIhFVg2tlAtuz
DashboardMaster your compliance tasks with an intuitive and powerful dashboard!/files/WLSZJ6IGp8SYFtOZS51U/pages/y6Rq68bxILudRvRAtwOF
ComplianceBuild Frameworks and controls to take your first steps through the compliance journey!/files/WOo99OJSTBsBY8aWcWGA/pages/nkpJmKEWQrS11BEn4QE0
PoliciesGet to know our Policies first-hand!/files/hnwTHSVMkbAh7eqjRONm/pages/ptpkXTzYZBjyQedTkPOD
### Explore more
Cover image
Risk & VendorsManage risks and vendor assessments/files/NjcUwHgCEPvAC52wwJdZ/pages/XoKIqCkvSt7pE4aVPKmR
TrustSetup security measures for your organisation with ease!/files/AWYJHiphc84P11RaxaHZ/pages/d3AmiRXbQRXQI068x8dd
SettingsManage your account with ease!/files/7DPesavSIZ6rNENGHgVs/pages/dNh2MGDHqRwqizGLBnkn
AI & Automation/files/eAg3QmPh5oAhp2Z5kBfw/pages/qrhCnizjNBT74Z3RdjdE
# Why Sprinto Sprinto enables businesses to streamline compliance operations effortlessly with automated workflows, real-time monitoring, and seamless integrations across security frameworks. Sprinto is a security compliance automation platform designed to help cloud-hosted companies meet and maintain compliance across standards like SOC 2, ISO 27001, GDPR, and more. Whether you’re aiming for audit-readiness, closing enterprise deals, or strengthening your security posture, Sprinto gets you there faster—with clarity, control, and confidence. ### What is Sprinto? Sprinto simplifies and automates the path to compliance by integrating with your existing cloud stack, continuously monitoring your systems, assigning responsibilities, and generating audit-ready reports. With Sprinto, compliance isn’t a one-time project—it’s a continuous, real-time capability built into your operations. ### Key Benefits * **Fast-track audits**: Automate 80% of manual effort with pre-mapped controls, integrations, and workflows. * **Real-time visibility**: Always know your compliance posture with live dashboards and reports. * **Audit readiness by design**: Maintain readiness with continuous monitoring, alerts, and evidence collection. * **Tailored controls**: Apply industry-standard frameworks with the flexibility to customise for your environment. * **One platform, multiple frameworks**: Manage SOC 2, ISO 27001, GDPR, HIPAA, PCI-DSS, and others in one place. * **Collaborative tooling**: Assign tasks, set deadlines, and work cross-functionally with your team and auditor in-platform. * **Expert guidance**: Get dedicated CSMs, audit partners, and compliance specialists to help you through. ### Features at a Glance
FeatureDescription
IntegrationsNative integrations with cloud providers, HRMS, source control, ticketing, etc.
Automated Evidence CollectionCollects screenshots, logs, and metadata automatically across systems.
Frameworks LibrarySupports multiple audit frameworks out of the box.
Continuous MonitoringMonitors controls, assets, users, and infrastructure for drift.
Audit WorkspaceCentralised hub for managing and collaborating on audits.
Risk ManagementIdentify, treat, and track risks through structured workflows.
Policy ManagementHost, version, and distribute security policies internally.
Access ReviewsPerform automated user access reviews across cloud systems.
Trust CenterShare your security posture transparently with customers and stakeholders.
### Who is it for? Sprinto is built for: * **Startups** looking to achieve first-time compliance * **Growth-stage companies** scaling their security programs * **Enterprises** managing multiple audits and teams * **Audit and InfoSec teams** aiming for automation, control, and visibility ### How it works Sprinto connects to your cloud environment, pulls in configuration and activity data, maps it to compliance controls, and continuously checks for alignment. Tasks are created, evidence is collected, and deviations are flagged—so you stay ready for an audit at any time. # Setup Guide A step-by-step guide to getting started with Sprinto—set up your account, configure governance, build a security programme, and manage risks for complete compliance readiness. **Kick-start your compliance journey with Sprinto in four simple steps.** This guide walks you through the essential setup actions to get your organisation up and running quickly. You’ll configure your account, set up governance, build your data security programme, and manage risks—ensuring a strong foundation for ongoing compliance. *** ### Before you begin * Ensure you’ve signed up for Sprinto and received your account activation email. * Add the right stakeholders as Sprinto admins. We recommend: * **People** – HR representative * **Infrastructure, Vulnerabilities, Change management** – Infrastructure admin * **Risks, Asset Register** – Compliance officer * **Reviews** – Compliance officer, senior management * Keep your compliance frameworks in mind—these will guide the configurations you enable. *** ### Walkthrough Video Here's a brief walkthrough video for the employee portal. {% embed url="" %} *** ### Step 1: Configure your Sprinto account 1. **Log in to Sprinto** * Use the sign-up link to access the admin portal. Log in with your credentials. * On first login, Sprinto will prompt you to set up your account. 2. **Set up your company profile** * Upload your company logo (256 x 256 px, .png or .jpg, max 2 MB). * Enter your **display name** (used in policies and documents) and **legal name** (used in audits and official letters). 3. **Invite admin users** * Add email addresses of admin users and click **Invite & Proceed**. * Invitees will receive a welcome email with their login details. 4. **Enable compliance frameworks** * Select the frameworks you want to enable. * Click **View** to review security controls, then **Add controls** to enable them. *** ### Step 2: Set up staff and organisational governance #### People * Add staff members via service integrations or manual entry (bulk upload or individual). * Assign **security roles** to define responsibilities. You can also create custom roles if needed. #### Policies * Create policies using Sprinto templates, upload your own, or draft them using the built-in editor. * Optionally, sync policies from Confluence. * Send policies for approval once finalised. #### Security trainings * Use Sprinto or integrate an external training provider. * Create and manage training campaigns for staff. #### Device management * Use **Dr. Sprinto** for device health reporting or integrate a third-party MDM solution. #### Staff onboarding * Configure onboarding workflows after adding staff, policies, and training. * Track onboarding progress and send reminders if needed. *** ### Step 3: Build your data security programme #### Access * Add critical access systems automatically (ACAS) or manually (MCAS). * Configure access controls, or integrate IAM tools for easier management. #### Infrastructure * Integrate infrastructure services for automated monitoring, or set up workflow checks for manual monitoring. * Classify resources—only **Production**-classified assets are monitored for compliance. #### Change management * Add code repositories, ticketing systems, or manual workflow checks. * Review and classify repositories. #### Vulnerabilities * Integrate a vulnerability monitoring source or manage manually. * Review and close reported vulnerabilities. #### Incidents * Use Sprinto or integrate an external system for incident management. * Review, manage, and report incidents. *** ### Step 4: Identify and mitigate risks #### Risk assessment * Add risks from the Sprinto library or manually. * Score risks and map mitigation plans. #### Vendor management * Add vendors using the vendor library, CSV upload, or vendor discovery (SSO-based). * Perform due diligence for high-risk vendors. *** ### Additional areas * **Trust Centre** – Showcase your compliance posture publicly. * **Security Questionnaires** – Maintain a centralised knowledge hub for customer questionnaires. *** ### Support Need help? * Visit our [Support Centre](mailto:support@sprinto.com) # Self‑Serve Dashboard Step‑by‑step, CTA‑driven guide to complete Sprinto’s SOC 2 Launchpad, generate your blueprint, and action policies, risks, and evidence. This guide walks you through the updated **linear onboarding** experience for the self‑serve dashboard. Each step is powered by Sprinto AI and requires you to confirm inputs or click through CTAs to progress. ### **Before you begin** * Use a work **email address**. * Have your website/domain handy for auto‑fetch (recommended). *** ### Step 1 – Review company details 1. Log in to your Sprinto account. 2. Sprinto AI auto‑fetches your organisation’s profile from public sources. 3. Review the gathered details (industry, data collected, data storage, code repository, infrastructure, tools, email provider).
4. If needed, click the **edit** icon to make changes. 5. You can edit the following details: 1. Organisation name 2. Industry 3. Data collected 4. Data storage locations 5. Email provider 6. Infrastructure 7. Code Repository 6. Click **Save** once you are done editing your organisation details.
7. Click **Looks good →** to continue. *** ### Step 2 – Generate policies 1. Sprinto AI analyses your inputs and begins drafting policies. 2. You will see a loading state: analysing industry, customising templates, applying branding. 3. Once complete, a list of policies is generated. 4. Review the policy list (e.g., Acceptable Usage Policy, Incident Response Plan, Business Continuity Plan). 5. Click **Add policies →** (or equivalent CTA) to proceed.
*** ### Step 3 – Generate risks 1. Sprinto AI identifies risks based on your vendors, infrastructure, and data flows. 2. Wait while AI estimates likelihood/impact and maps risks to mitigation controls. 3. Review the risk list once displayed (e.g., Data compromisation, Supply chain disruption, AI model degradation). 4. Risk levels are marked as **High**, **Medium**, or **Low**. 5. Click **Add 14 risks →** (or equivalent CTA) to confirm and continue.
*** ### Step 4 – Add tools 1. Sprinto AI auto‑detects third‑party tools your organisation uses. 2. Review the suggested tool list. 3. Remove tools not in use, and use the search bar to add missing ones. 4. When satisfied, click **Add tools →** to finalise.
*** ### Step 5 – Generate Letter of Engagement 1. Sprinto AI compiles your inputs (policies, risks, vendors, tools). 2. A **Letter of Engagement (LoE)** is generated confirming your SOC 2 compliance journey is underway. 3. Options: * **Download** the LoE. * **Share on LinkedIn**. 4. Once ready, click **Proceed →** to continue to the Monitoring phase.
*** ### End of linear onboarding At this point you have: * Confirmed your organisation profile. * Generated and approved baseline policies. * Identified and logged key risks. * Added your tools. * Received your Letter of Engagement (LoE). You are now 25% audit‑ready and can move on to Monitoring in the dashboard. *** ### Notes * You can always edit details later if something changes. * Invite collaborators at any stage using the **Invite collaborator** button. * Use **Talk to expert** for live assistance during onboarding. # Sprinto Policies ## Overview Sprinto maintains a comprehensive set of organisational and security policies designed to safeguard data, ensure compliance, and establish clear responsibilities for staff, contractors, and third parties. These policies provide the framework for how Sprinto manages information security, business continuity, vendor relationships, and operational practices. The policies define expectations for acceptable use, access control, incident management, vendor management, human resources security, physical and environmental security, and more. They apply to all staff members and external parties who interact with Sprinto systems, data, or facilities. Each policy outlines its objective, scope, and key requirements. Together, they support Sprinto’s commitment to: * Protecting the confidentiality, integrity, and availability of information assets. * Complying with relevant legal, regulatory, and contractual requirements. * Ensuring continuity of operations and resilience against disruptions. * Maintaining transparency, accountability, and professional conduct across the organisation. The content of these policies has been standardised for inclusion in the self-serve dashboard. No modifications have been made to the text to ensure that all staff members can access the approved versions in their original form. *** ### Policy Index #### Information Security | | | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Information Security Policy | Establishes principles and objectives for confidentiality, integrity, and availability of information. | | Communications & Network Security Policy | Defines requirements for protecting networks, communication channels, and information transfer. | | Network Security Procedure | Outlines responsibilities and controls for protecting Sprinto networks and services. | | Organisation of Information Security Policy | Defines ISMS governance, responsibilities, and segregation of duties. | #### Access and Asset Management
Policy/ProcedureDescription
Access Control PolicyEstablishes a framework for controlled access to systems and data based on least privilege.
Access Control ProcedureDetails the procedure for user access management and removal of rights.
Acceptable Usage PolicyDefines responsible and prohibited use of company systems, devices, and accounts.
Asset Management PolicyEnsures assets are classified, tracked, and protected from unauthorised access or misuse.
Asset Management ProcedureProvides a formal process for maintaining, handling, and protecting information assets.
Media Disposal PolicyProvides guidance on secure disposal of media to prevent unauthorised data recovery.
#### Human Resources and Conduct | Policy/Procedure | Description | | ------------------------------- | ---------------------------------------------------------------------------------------------------- | | HR Security Policy | Defines information security requirements for staff and contractors across the employment lifecycle. | | HR Security Procedure | Specifies HR-related security steps before, during, and after employment. | | Code of Business Conduct Policy | Sets expectations for professional behaviour, integrity, and conduct. | #### Operations and Development | Policy/Procedure | Description | | ---------------------------------------- | --------------------------------------------------------------------------------------------------- | | Operation Security Policy | Defines controls to ensure secure operations, including change management, logging, and monitoring. | | Operations Security Procedure | Details procedures for backup, vulnerability management, and change handling. | | Software Development Lifecycle Policy | Ensures security is embedded throughout the system development lifecycle. | | Software Development Lifecycle Procedure | Outlines secure practices and responsibilities across software development stages. | #### Incident and Continuity Management | Policy/Procedure | Description | | ---------------------------------------------- | ---------------------------------------------------------------------------------------- | | Incident Management Policy | Provides a framework for reporting, responding to, and learning from security incidents. | | Incident Management Procedure | Defines the procedure for handling, classifying, and remediating security incidents. | | Business Continuity & Disaster Recovery Policy | Outlines plans for continuity of operations and disaster recovery. | | Business Continuity Plan | Provides step-by-step guidance for responding to extended outages or disasters. | #### Vendor and Compliance | Policy/Procedure | Description | | --------------------------- | -------------------------------------------------------------------------------------------------------- | | Vendor Management Policy | Defines requirements for managing vendor relationships and associated risks. | | Vendor Management Procedure | Provides responsibilities and steps for monitoring vendor contracts, risks, and performance. | | Compliance Policy | Establishes guidelines for managing compliance with statutory, regulatory, and contractual requirements. | | Compliance Procedure | Details methods for identifying and managing compliance requirements and audits. | #### Physical and Environmental Security | Policy/Procedure | Description | | ------------------------------------------- | ------------------------------------------------------------------------------------------- | | Physical & Environmental Security Policy | Establishes requirements for securing office premises, remote work, and physical access. | | Physical & Environmental Security Procedure | Provides detailed procedures for protecting assets, facilities, and staff responsibilities. | *** Would you like me to also **add a short one-line SEO description** for this overview page, in line with your other Sprinto documentation pages? # Acceptable Usage Policy ## 1 Objective \ is committed to safeguarding the data processed by its staff, software, or services. Our customers, partners, and other stakeholders depend on us to take appropriate measures to protect the data in our possession. Thus, each staff member needs to understand how to responsibly use our systems so that we appropriately safeguard the data in our possession. ## 2 Scope This policy applies to all staff members, including employees, contractors, consultants, temporary, and other workers that interact with \ systems. All such individuals are responsible for exercising good judgment in appropriately using electronic devices, data, and network resources in accordance with policies and standards, local laws, and regulations. This policy applies to: * Any company-issued electronic, computing, storage, or network device. * Any company-owned systems on the Internet or Intranet accessed wirelessly, including but not limited to servers, software, operating systems, storage, and network accounts. * Any company-administered accounts with third-party services providing email, storage, infrastructure, software, data, APIs, business systems, etc., irrespective of whether such accounts are accessed via devices owned/leased by the company or are owned by staff members or a third party. ## 3 Policy Statement \ has a culture of trust and integrity. This policy aims to reinforce the trust we place in each other by ensuring we can collectively depend on each other to protect the assets of our staff, company, partners, and customers. Security is a company-wide effort and requires cooperation from every staff member who works with \ systems. Individuals should take precautions to ensure they use systems appropriately and not deliberately or inadvertently perform destructive or illegal actions. ## 4 Separation of Concerns Company-issued devices and accounts are not personal property, so limiting their use for personal reasons is strongly recommended. ## 5 Security of Critical Data * All data stored on computing and storage devices, whether owned or leased by \, the employee, or a third party, remains the sole property of \. * You must ensure that all critical data is handled and secured in accordance with the Data Classification Policy. * You are required to promptly report theft, loss, or unauthorized disclosure of any critical data. * You may access, use, or share critical data only to the extent authorized and necessary to perform your job responsibilities. * Staff members are responsible for exercising good judgment when using \ systems for reasonable personal use. If there is any uncertainty, staff members must consult their supervisor or manager. * \ reserves the right to audit any system at any time to ensure compliance with this policy. Authorized individuals within \ may monitor equipment, systems, and network anytime. ## 6 Unacceptable Use Staff members may not use \-managed resources for activities that are illegal or prohibited under applicable law, no matter the circumstances. ### 6.1 Unacceptable System & Network Activities * Violations of the rights of any person or company protected by copyright, trade secret, patent, or other intellectual property, or similar laws or regulations. * Unauthorized copying, distribution, or use of copyrighted material. * Exporting software, technical information, encryption software, or technology in violation of international or national export control laws. * Intentional introduction of malicious programs into \ networks or any \-managed computing device. * Intentional misuse of any \-managed computing device or \ networks (e.g., for cryptocurrency mining, botnet control, etc.). * Sharing your credentials for any \-managed computer or 3rd party service that \ uses with others, or allowing the use of your account or a \-managed computer by others. This prohibition does not apply to single-sign-on or similar technologies, the use of which is approved. Using a \ computing asset to procure or transmit material that is in violation of sexual harassment policies or that creates a hostile workplace. * Making fraudulent offers of products, items, or services originating from any \ account. Intentionally accessing data or logging into a computer or account that the team member or contractor is not authorized to access, disrupting network communication, or computer processing or access. * Executing any form of network monitoring that intercepts data not intended for the team member’s or contractor's computer, except when troubleshooting networking issues for the benefit of \. * Circumventing user authentication or security of any computer host, network, or account used by \. * Tunneling between network segments or security zones, except when troubleshooting issues for the benefit of \ and its customers. ### 6.2 Unacceptable Email & Communications Activities * Forwarding confidential business emails or documents to personal external email addresses. * Note: \ may retrieve messages from archives and servers without prior notice if \ has sufficient reason to do so. If deemed necessary, this investigation shall be conducted with the knowledge of the Information Security Officer, Senior Management, People Business Partners, and the Legal team. ### 6.3 Return of \-Owned Assets All \ owned computing resources should be returned upon separation from the company. ## 7 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 8 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 9 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 10 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # Access Control Policy ## 1 Objective The objective of this policy is to provide a framework to ensure that access to \ assets is provided in a controlled manner based on business and information security requirements. The framework is designed to ensure that appropriate controls for access management are established to protect \ assets from security threats arising from unauthorized access. ## 2 Scope This policy applies to specific systems that, from an access standpoint, have significant implications on \’s ability to render its service commitments and safeguard information. ## 3 Policy Statement Centralized access control is key to ensuring that the correct \ staff members access the correct data and systems at the correct level. The principle of least privilege guides \’s access controls. These controls apply to information and information processing systems at the application and operating system layers, including networks and network services. The confidentiality, integrity, and availability of information stored within the information system of \ shall be assured by ensuring that only authorized users have access to specific information assets as needed for their business activities. ## 4 Access Control Policy ### 4.1 Requirement for Access Control * Every organization possesses information and information assets that need to be protected from unauthorized use. * A list of critical systems within \ that host services or sensitive data as defined in the scope of this document shall be identified and documented. * It is the responsibility of the Information Security Officer to ensure all such systems used to meet business requirements at \ are identified, and the list of critical systems is kept updated. ### 4.2 Access Management #### 4.2.1 Access Provisioning * \ shall provide access privileges to its systems based on the following principles: * Need to know – users or resources shall be granted access to systems that are necessary to fulfill their roles and responsibilities. * Least privilege – users or resources shall be given minimum privileges necessary to fulfill their roles and responsibilities. * Separation of duties – the practice of ensuring responsibility to perform critical actions is distributed among different individuals to keep a single individual from subverting the process. * The minimum requirements for access control are to be achieved using one or both of the following methodologies: * Role-based Access control: This methodology restricts access to systems and resources based on individuals or groups with defined business functions -- e.g., executive level, engineer level 1, etc. -- rather than the identities of individual users. * Rule-based access control: This involves a formal registration and de-registration process for individual users where access is provided based on requests and approvals from authorized personnel. * For Role-based access Control: * Access to information systems and services is restricted based on the role assigned to staff members. * The roles that may access each critical system shall be identified and documented. * By default, staff members are granted access to systems according to their role or team. The ability to grant access to systems is restricted to the administrators of each system. * If any access is required outside the defined role matrix, the business justification for such an event must be documented. * For Rule-based/ Ticket-Based access control: * Requests for users’ accounts and access privileges must be formally documented and appropriately approved. Access authorization information for a user must be retained for a minimum amount of time as defined in business, contractual, and legal requirements. * For any staff member requiring access to systems/platforms/tools, a request needs to be submitted detailing the specific access being requested. * The Acceptable Usage Policy needs to be accepted by an employee before being granted access to systems that contain customer data. This policy outlines responsibilities and commitments regarding the acceptable use of the \'s assets. * If a \ staff member requires access outside of the default for their role or team, either they or their managers may request additional access to the administrators of the respective systems. * When granting such access, it shall be limited to the minimum level required to perform the intended business operation. #### 4.2.2 Management of Privileged Access Rights * \ operates its access management under the principle of least privilege. * Under the principle of least privilege, a staff member should only be granted the minimum necessary access to perform their function. Access is considered necessary only when a \ staff member cannot perform a function or action without that access. If an action can be performed without the requested access, it's not considered necessary. The least privilege is important because it protects \ and its customers from unauthorized access and configuration changes and in case of an account compromise by limiting access. #### 4.2.3 Management of Passwords and Secret Authentication Information of Users * It is recommended to minimize the use of passwords wherever possible. Please follow the guidelines to reduce the reliance on passwords: * Use a single-sign-on mechanism to authenticate yourself wherever possible. This avoids the need to create new strong passwords. Please ensure that the password/authentication mechanism for the SSO system is secure * Use multi-factor authentication (MFA) techniques to authenticate yourself wherever possible. This adds an additional barrier even if the password is compromised * Where passwords are the only way to login to a system, it is recommended to consider the below security requirements: * Staff members must use complex passwords, wherever possible, for all of their accounts that have access to critical data. A strong password should consist of at least 8 characters and should contain a combination of alphanumeric + special characters * It is strongly recommended against the reuse of passwords that are or were used elsewhere, e.g., passwords used for personal accounts. A common way attackers obtain access to corporate resources is by using employees’ personal passwords that were obtained in breaches of other services * \ shall ensure that any password or authentication details stored within systems owned and managed by \ should be encrypted or masked to avoid exposing such details #### 4.2.4 Review of Access Rights * There shall be a periodic reconciliation of user accounts and the associated rights. The reconciliation needs to be performed at least annually. * Review of access rights must also include a review of privileges assigned to users. * It is essential that appropriate actions are taken immediately to remove, disable, or modify any irregularities found in the access reconciliation. #### 4.2.5 Removal or Adjustment of Access Rights * Employment termination or change of roles shall trigger relevant processes for revoking or amending access rights. * If there is a role change, necessary changes/adjustments shall be made so that the user does not have more rights than required to carry out the new job function. * The removal or modification of access rights for terminated \ employees or contract staff shall be carried out by the relevant administrators. #### 4.2.6 Secure Log-On Procedures * Following shall be considered for security when accessing critical systems: * If the login is unsuccessful, the error message shall not display which part of the login information was incorrect. * Limit the number of unsuccessful log-on attempts. * Password shall not be displayed while it is being entered. * Multi-factor authentication shall be adopted wherever possible. * Using an authentication mechanism like single sign-on (SSO) is also recommended wherever possible. * Session Time-Out * Inactive sessions (Application sessions, Administration Sessions, etc.) shall be shut down where feasible after a defined period of inactivity. * Intranet site may be exempted from the requirement of session time-out. * Session time-out requirements shall be implemented for all the critical systems as feasible and applicable. * Re-authentication may be considered at timed intervals. #### 4.2.7 Access Monitoring * For all production infrastructure, logging must be enabled to ensure user accountability is maintained in case of any issues. It is recommended to have additional security measures like an intrusion detection/prevention system to detect any unauthorized access. ## 5 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 6 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 7 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 8 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization.
# Business Continuity & Disaster Recovery Policy ## 1 Objective The objective of this policy is to provide guidelines for \’s business continuity and disaster recovery. The document prescribes the requirements to plan for recovery during disasters so that business commitments to customers can always be met. ## 2 Scope This document is applicable to all processes and operations in \ within the scope of the ISMS. ## 3 Policy statement \ is committed to ensuring the highest level of service to its customers. Thus continuity of operations in a secure manner must be planned for and embedded in the organization’s business continuity management and disaster recovery planning activities. ## 4 Information Security Aspect of Business Continuity Management ### 4.1 Information Security Continuity #### 4.1.1 Planning Information Security Continuity * The organization-wide Information security processes shall include Information Security requirements to help ensure that confidentiality, integrity, and availability of critical information assets shall be preserved even in the event of a business disruption or disaster. * \ shall identify recovery guidelines that can be taken as a baseline reference to classify mission-critical systems and develop recovery and restoration plans. * A strategy plan shall be developed for the overall business continuity/disaster recovery approach. Information security controls applicable during BAU (Business as usual) scenarios shall be relevant even during disaster scenarios. All exceptions shall need approval from the Information Security Officer and senior management. #### 4.1.2 Implementing Information Security Continuity * \ shall ensure that an adequate framework is in place to prepare for, mitigate, and respond to a disruptive event using personnel with the necessary authority, experience, and competence. * \ shall identify personnel with the necessary responsibility, authority, and competence to manage an incident and maintain information security. * \ should consider the development and approval of comprehensive and well-documented plans, response strategies, and recovery procedures to effectively manage and mitigate the impact of any potential disruptive event. #### 4.1.3 Verify, Review & Evaluate Information Security Continuity * Information security controls for all business continuity sites and systems shall be reviewed and verified. Business continuity plans shall be tested and updated regularly to ensure they are up-to-date and effective. * The roles and responsibilities for both information systems’ contingency planning and recovery shall be reviewed and updated at least annually. ### 4.2 Redundancies * \ shall identify business requirements for the availability of information systems. * Redundant components or architectures shall be considered wherever availability cannot be guaranteed using the existing systems architecture. * Redundant information systems shall be tested to ensure the successful failover from one component to another. ## 5 Document Security Classification Company Internal (please refer to the Data Classification policy for more details). ## 6 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 7 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 8 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # Code of Business Conduct Policy ## 1 Objective \’s Code of Business Conduct policy outlines the company’s expectations regarding employees' behavior towards their colleagues, supervisors, and the overall organization. \ promotes freedom of expression and open communication. All staff members are expected to follow the code of conduct. Staff members should avoid offending others, participating in serious disputes, and disrupting our workplace. \ also expects all staff members to foster a well-organized, respectful, and collaborative environment. This policy outlines the expectations for all \ staff and the consequences for unacceptable behavior. ## 2 Scope This policy applies to all \ staff members. Staff members include employees (both full-time and part-time) as well as contractors, regardless of the employment agreement or the level of seniority. \ staff members are expected to follow this policy in all matters pertaining to their work. ## 3 Policy Statement \ is committed to creating and maintaining a professional and respectful work environment. This policy describes the desired behavior of all staff members and emphasizes the importance of diversity and inclusion in the workplace. ## 4 Guidelines * Be welcoming, friendly, and patient. * Be considerate. Other people will use your work, and you, in turn, will depend on the work of others. Any decision you make will affect users and colleagues, and you should take those consequences into account when making decisions. * Be respectful. Not all of us will always agree, but disagreement is no excuse for poor behavior and manners. Everyone experiences some frustration occasionally, but one cannot allow that frustration to become a personal attack. It's important to remember that an organization where people feel uncomfortable or threatened is not productive. \ Staff should be respectful when dealing with other staff. * Be careful with the words that you choose. Remember that sexist, racist, and other exclusionary jokes can offend those around you. Be kind to others. Do not insult or put down others. Behave professionally. Remember that harassment and sexist, racist, or exclusionary jokes are inappropriate for the organization. Such unacceptable behavior includes, but is not limited to: * Violent threats or language directed against another person. Discriminatory jokes and language * Posting sexually explicit or violent material. * Posting (or threatening to post) other people's personally identifiable information ("doxing"). Personal insults, especially those using racist or sexist terms. * Unwelcome sexual attention. * Advocating for or encouraging any of the above behavior. * Repeated harassment of others. In general, if someone asks you to stop, then stop. * When there is a disagreement, efforts should be made to try to understand why. Social and technical disagreements happen all the time, and \ is no exception. Disagreements and differing views must be resolved constructively. Remember that everyone is different. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn't mean they're wrong. Remember that it is human to err. Blaming each other doesn't help. Instead, offer to help resolve issues and to help learn from mistakes. * The company requires that all staff members demonstrate commitment to impartially treating all people and organizations with whom they come into contact or conduct business. Unsolicited gifts or entertainment may only be accepted if they do not go beyond common courtesy and do not have a risk of influencing any business decisions. * \ requires all staff members (including senior management) to disclose any personal relationships, business transactions, and related parties that might cause reputational/financial harm to the organization while benefiting them. * \ requires all staff members that they do not offer, give, receive, or solicit anything of value to influence an official act by a public official, agent, or government employee. * \ prohibits all staff members from bribing foreign officials as well as making unauthorized facilitation payments to those individuals involved in customs, permitting the flow of goods and other activities. ## 5 Reporting Violations If you are a victim of or notice unacceptable behavior, please notify your reporting manager or anyone up the reporting structure, including the CEO. Note that this policy does not allow retaliation against a person for reporting unacceptable behavior or participating in an investigation of any such report. Disciplinary actions listed below also apply to any such retaliation or intimidation. ## 6 Document Security Classification Company Internal (please refer to the Data Classification policy for more details). ## 7 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 8 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 9 Schedule This document is to be reviewed annually and whenever significant changes occur in the organization. # Communications & Network Security Policy ## 1 Objective \ shall take adequate precautions and design appropriate controls to prevent misuse of its information assets and information processing facilities. In this regard, \ shall establish necessary communication and network security procedures, protect information in networks and support infrastructure, maintain the security of information being transferred, and detect any unauthorized information processing activities. ## 2 Scope This document applies to all processes and operations within the scope of the Information Security Management System at \. ## 3 Policy Statement \ is committed to ensuring the highest level of service to its customers. Consequently, it is paramount to manage and control networks to protect them from threats and maintain the security of their systems and applications. ## 4 Communication & Network Security ### 4.1 Network Security Management #### 4.1.1. Network Controls * Networks shall be adequately managed and controlled to be protected from threats and to maintain the security of the systems and applications using the network, including information in transit. * Network-based intrusion prevention/detection system shall be deployed, wherever possible, to cover critical network segments within IT infrastructure. * Infrastructure elements and software(s) exposed to un-trusted or semi-trusted networks/users (e.g., Internet-facing systems, distributors, call centers, Contract Partners, etc.) shall be adequately protected by firewalls, Intrusion Prevention Systems (IPSs), and limited connectivity and encryption. * Any system deployed on the Internet must go through a thorough vulnerability check. * All configurations must be done by trained and authorized personnel. Any changes to network configurations should follow the Operations Security Procedure. * Vulnerability assessment of these infrastructure elements shall be carried out every year. * All end-user systems connecting to the \ infrastructure should have baseline security implemented. #### 4.1.2. Information Transfer Policies & Procedure * Users shall be made aware, and information transfer guidelines shall be captured in the Data Classification Policy and Asset Management procedure, and users shall be made aware of these guidelines. * Acceptable use standards shall be established to define guidelines for the appropriate use of communication facilities. * Appropriate anti-malware controls shall be established to detect and prevent malware that could be transmitted through electronic communication channels. * Employees shall treat all correspondence sent using \ email systems as confidential. * To prevent loss, modification, destruction, or misuse of information, \ shall protect and control the exchange of critical business information assets and software with third parties and outside organizations. * Where feasible, it is recommended to consider the implementation of appropriate web filtering mechanisms that will restrict user access to external networks and websites based on the organization’s policies. #### 4.1.3. Electronic Messaging * Information involved in electronic messaging (e.g., emails, instant messengers) shall be appropriately protected from unauthorized access, modification, or denial of service. * Public email accounts shall not be used for conducting \ operations unless authorized. * Forwarding of \ mailbox to public or non-\ email accounts shall be done in accordance with the Data Classification policy. #### 4.1.4. Confidentiality or Non-Disclosure Agreements * Confidentiality or non-disclosure agreements reflecting \ needs for the protection of information shall be identified and maintained with all the third parties, and this will be based on the criticality of the information to be protected. These requirements shall be reviewed at least once in a year and at the time of any change in the business environment, legal requirements, and contractual obligations. * Confidentiality and non-disclosure agreements shall comply with all applicable laws and regulations for the jurisdiction to which they apply. * Both staff members and contract partners of \ shall sign and comply with the non-disclosure agreement (NDA) that is established and maintained by the \'s HR team, where applicable. ## 5 Document Security Classification Company Internal (please refer to the Data Classification policy for more details). ## 6 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 7 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 8 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # HR Security Policy ## 1 Objective The objective of this policy is to provide a framework within which the information security requirements of human resources are addressed throughout the entire lifecycle of recruitment, employment, change of employment, and termination. \ shall ensure that employees (full-time and part-time) and external parties, including contractors and other third-party staff, understand the responsibilities for the roles they are considered for and are aware of and fulfill their information security responsibilities. Additionally, \ shall protect the company's interests while changing or terminating employment. ## 2 Scope This policy applies to all employees (full-time and part-time) and external parties, including contractors and other third-party staff (including housekeeping staff and security personnel), with access to \ information systems. ## 3 Policy Statement \ shall ensure that employees (both full-time and part-time) and external parties, including contractors and other third-party staff, understand their responsibilities for the roles they are considered for and are aware of and fulfill their information security responsibilities. Moreover, \ shall also protect the company’s interests while changing or terminating employment. ## 4 Human Resource Security Guidelines ### 4.1 Before employment * As part of the hiring process, the competence of all candidates considered for employment shall be evaluated to ensure that they can perform the expected job responsibilities. * Once employed, all \ employees and contract partners shall sign the terms and conditions of employment, which shall include the employee’s responsibilities for information security and related obligations, both during and after employment. * Background verification checks shall be performed on all prospective employees where possible: * The extent of background verification checks will be proportional to business requirements, the classification of information to be accessed, and the perceived risks. This may include previous employment checks, confirmation of claimed academic and professional qualifications, identity checks, or criminal record checks for prospective \ employees. * In specific geographies, background verification checks may be considered illegal. In such cases, you may consider conducting a reference check depending on the level of information accessible to such employees. * Considering privacy, protection of personal data, and other relevant employment laws and regulations that may be applicable, contract partners shall be assessed for their information security practices as part of the Vendor Risk assessment. For more details, please refer to the Vendor Management Policy. ### 4.2 During Employment * Roles and responsibilities related to Information Security shall be defined and documented for all employees (full-time and part-time), contractors, and third-party staff where applicable. * All employees, relevant contractors, and third-party staff shall receive appropriate awareness training on organizational policies and procedures, including security requirements, legal responsibilities, and other controls, such as understanding the acceptable use of \ systems and the Code of Business Conduct at \. * Awareness training on organizational policies shall also be conducted upon joining and at least once a year thereafter. * Formal information security training shall be provided to employees upon joining and at least once a year thereafter. * Organizational policies and the formal information security training deck shall be available to all employees on a public portal. * The Information Security Officer shall be responsible for implementing and complying with information security controls by all employees. 3. ### Termination or Change in Employment * Upon termination, \ employees shall return/hand over the organization's assets under their purview. * Upon termination, all access rights and privileges to critical information systems granted to employees or contractors shall be revoked according to the access control policy. * In the case of a change in employment status, access rights and privileges to critical information systems granted to employees and contractors shall be reviewed and adjusted accordingly. ## 5 Document Security Classification Company Internal (please refer to the Data Classification policy for more details). ## 6 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 7 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 8 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization.
# Incident Management Policy ## 1 Objective The objective of this policy is to provide a framework within which information security events and incidents associated with information systems are communicated in a timely manner and necessary corrective actions are taken. ## 2 Scope This document is applicable to all processes and operations in \ within the scope of the ISMS. ## 3 Policy Statement Security incidents are irregular and anomalous conditions that cause — or may lead to — service degradation, loss of sensitive data, outages, or any form of reduced operational status. These situations require quick human intervention to avert disruptions or restore the operational status. This document offers guidance and establishes methods for handling and managing incidents for the staff or incident responders who believe they have discovered or are responding to a security incident. ## 4 Information Security Incident Management ### 4.1 Responsibilities and Procedures * An Incident management procedure shall be created to define procedures and responsibilities to ensure quick, effective, consistent, and orderly responses to information security incidents. * There shall be responsible personnel appointed for: * Investigation/coordination of the reported information security incidents and security weaknesses. * Tracking closure of incidents and corrective and preventive actions. ### 4.2 Reporting Information Security Events and Incidents * \’s management shall establish appropriate channels through which information security incidents can be reported as quickly as possible. * All information security incidents shall be recorded in an information security incident database. * The details of the steps to be followed for reporting an incident shall be communicated to all employees and contractors of the company. * Incident reporting and management procedures shall be made available for easy access and reference for reporting security incidents and weaknesses by the users. * A monitoring mechanism shall be set up for proactive monitoring of intrusions, attacks, and frauds. ### 4.3 Assessment of and Response to Information Security Incidents * All information security incidents that are reported shall be assessed and classified as per the classification criteria mentioned in the incident management procedure. * The assessment and classification of incidents shall be maintained for future reference to allow easy identification and avoid false positives. * A response plan and strategy for the appropriate handling of security incidents shall be formulated, which covers the incident cycle from identification to root cause analysis to resolution. * The overall response to reported incidents shall include the identification of corrective action where important. * Where a follow-up action against a person or organization after an Information Security Incident involves legal action (either civil or criminal), evidence shall be collected, retained, and presented to conform to the rules for evidence laid down in the relevant jurisdiction. ### 4.4 Learnings from Security Incidents * The analysis shall be carried out for the information security incidents and shared with the appropriate authorities periodically. * Knowledge gained from the resolution of security events shall be used to reduce the likelihood of similar incidents in the future and help with limiting the impact of the incident. ## 5 Document security classification Company Internal (please refer to the Data Classification policy for more details). ## 6 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 7 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 8 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization.
# Information Security Policy ## 1 Objective While providing \’s service to clients, \’s staff members and vendors acquire access to the client's privileged and sensitive information. Each of \'s clients places an enormous amount of trust that their data is created, stored, shared, and transmitted securely. The loss of any client data or services due to unauthorized access, intrusion, theft, natural or cyber disasters, or cyber-attacks diminishes the client's trust as well as significantly damages \’s reputation as an advocate for companies to develop, implement and maintain systems to prevent the loss of intellectual property and other confidential information. The purpose of this policy document is to define the direction, principles, and basic rules for information security management within \. This document describes the management's vision and commitment to effectively protect "confidentiality," maintain "integrity," and ensure the "availability" of its information assets and to respond and recover from information security incidents when they arise. Information security is deemed to safeguard three main objectives: * Confidentiality – Data and information assets must be confined to people authorized to access them and not be disclosed to others. * Integrity – Keeping the data intact, complete, and accurate, and information systems operational. * Availability – An objective indicating that information or system is at the disposal of authorized users when needed. ## 2 Scope This policy is applicable to the following: * All staff members working for \ who have access to the organization's and client’s information. * All staff members, vendors, and third-party employees who have access to \’s information processing systems and the data contained in them. This includes the data accessed by licensed third parties, which is, in turn, deployed to and used by their clients. * All stakeholders and interested parties who are relevant to the operations of \. * All digital and non-digital assets that play a role in the creation, storage, transmission, and disposal of information come under the purview of this policy. ## 3 Policy Statement * \ shall establish, implement, and maintain a holistic and robust Information Security Management System (ISMS). ISMS is defined as the overall management system, based on a business risk approach, to establish, implement, operate, monitor, review, maintain, and improve information security. The management system includes organizational structure, policies, planning activities, responsibilities, practices, procedures, processes and resources. * The ISMS shall have adequate and appropriate arrangements which shall enable it to effectively protect "confidentiality," maintain "integrity" and ensure "availability" of its information assets and to respond and recover from information security incidents when they arise. * While planning the ISMS, \ shall consider its internal and external issues along with the requirements of the interested parties and determine risks and opportunities thatwhich could affect the activities supporting the provision of its products and services. The top management shall provide the required resources and sufficiently contribute towards the ISMS, ensuring it achieves its intended outcome(s). ## 4 Information Security Requirements * Information and supporting technology - including hardware and software systems, are critical business assets. Confidentiality, integrity, and availability of information are essential to maintaining a better competitive edge, profitability, legal compliance, and reputation. * Organizations and their information systems and networks increasingly face security threats from a wide range of sources, including external hacking and intrusions, computer-assisted fraud, espionage, sabotage, vandalism, or damage from natural disasters. Due to the dependence on information systems and services, organizations are now more vulnerable to security threats. * Designing security controls and implementing them requires careful planning and attention. Management policies and administrative controls are needed to supplement technical controls that are implemented to protect data. Information Security Management needs, at a minimum, participation from all employees in the organization. It may also require involvement from suppliers, vendors, service providers, customers, and external specialists. ## 5 Information Security Objectives The objectives of the Information Security Policy are: * To create a coherent system for the management of information security that is aligned with \’s business strategy. * To protect and safeguard the information that is important to \ and its clients. * To reduce risk related to the use of technology and technology outsourcing. * To ensure that all \'s information assets are accounted for and adequately protected from damage, alteration, loss, and unauthorized use or access. * To ensure that information and information systems are available only to authorized users. * To ensure that \ provides its customers with the means to enable them to fulfill their obligation to facilitate the exercise of Personally Identifiable Information (PII) principals’ right to access, correct, or erase PII pertaining to them, defined by the contract. * To ensure that PII processed under a contract shall not be processed for any purpose independent of the instructions of \’s customer. * To be compliant with all information security-related regulatory and statutory requirements pertaining to information collection, storage, processing, transmission, and disclosure. * To set aside resources to establish, implement, operate, monitor, review, and maintain information security safeguards. * To create awareness of information security and to ensure that all employees understand their responsibilities for maintaining information security. * To create detailed information security best practices and guideline documents and ensure compliance with such documents. * To assess and update the information security policy objectives periodically as per the business need and ensure continuous improvement. ## 6 Segregation of Duties * Segregation of duties is a method for reducing the risk of accidental or deliberate misuse of an organization’s assets. * While assigning responsibilities, conflicting duties and areas of responsibility shall be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization’s assets. * Care shall be taken that every individual may access, modify or use assets with proper authorization or detection. The possibility of collusion should be considered while designing the controls. ## 7 Contact with Special Interest Groups Based on requirements and proper vendor validation, specialist advice shall be sought whenever required. This could be by having a Security Consultant on a contractual or per-call payable basis. The same could also be sought from non-profit agencies. ## 8 Contact with Authorities Where required, the organization shall maintain appropriate contact with law enforcement authorities, regulatory bodies, fire departments, emergency services, telecommunication providers, and others. These contacts shall ensure help can be availed of and is accessible during a crisis. ## 9 Information Security in Project Management Information security should be integrated into the organization’s project management method(s) to ensure that information security risks are identified and addressed as part of a project. This applies generally to any project regardless of its character. Examples: a project for a core business process, IT, facility management, and other supporting processes. ## 10 Reporting of Security Incidents The person witnessing an information security incident should report the incident in the Sprinto Application. ## 11 Maintenance of Policy * Compliance with this policy and supporting policies shall be audited yearly. Exceptions identified during the audit shall be immediately and appropriately addressed. * The security policy shall be reviewed annually, except in the event of a major change in the organization or the environment affecting the organization, in which case it shall be reviewed on a need basis. * The security policy shall be reviewed and revised whenever a major security risk or incident is identified. ## 12 Supporting Policies The following policy documents shall support the information systems security policy at a minimum: #### 12.1. Human Resources Security Policy The purpose of this policy is to ensure that employees and contractors understand their responsibilities and are suitable for the roles for which they are considered. #### 12.2. Risk Management Procedure The purpose of this procedure is to ensure that guidelines related to understanding and managing risks that may affect information security are provided. #### 12.3. Access Control Policy The purpose of this policy is: * To limit access to information and information processing facilities. * To ensure authorized user access and to prevent unauthorized access to systems and services. * To make users accountable for safeguarding their authentication information. * To prevent unauthorized access to systems and applications. * Segregation of duties. #### 12.4. Asset Management Policy The purpose of this policy is: * To identify \’s assets and define appropriate protection responsibilities. * To ensure that information receives an appropriate level of protection in accordance with its importance to \. * To prevent unauthorized disclosure, modification, removal, or destruction of information stored on media. #### 12.5. Operations Security Policy The purpose of this policy is to ensure the protection of information through daily operations that take place in providing \’s services #### 12.6. Acceptable Usage Policy * To ensure that all employees at \ are aware of the acceptable use of assets and formal cybersecurity guidelines to ensure best security practicespractice. * To ensure that \’s information is protected when accessed, processed, or stored at teleworking sites. #### 12.7. Compliance Policy The purpose of this document is to ensure \ complies with all legal and regulatory requirements to ensure the proper functioning of all business domains. #### 12.8. System Acquisition and Development Policy The purpose of this policy is to ensure that information security is an integral part of information systems across the entire lifecycle. This also includes the requirements for information systems that provide services over public networks. #### 12.9. Physical and Environmental Policy This policy helps to prevent unauthorized physical access, damage, and interference to \’s information and information processing facilities. #### 12.10. Business Continuity Management Policy The purpose of this policy is to ensure that business continuity is embedded in \’s scope of operations. #### 12.11. Vendor Management Policy The purpose of this policy is to ensure the protection of \’s assets that are provided by third-party suppliers. #### 12.12. Incident Management Policy This policy helps the management of any information security incidents that may compromise confidentiality, integrity, or availability of data and services by \. ## 13 Document Security Classification Company Internal (please refer to the Data Classification policy for more details) ## 14 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 15 Responsibilities * The Information Security Officer has the ultimate authority over the Information Security Policy and approves and authorizes all changes to the Information Security Policy. * The Information Security Officer has executive authority over information security and works with Executive Management to approve, authorize, and issue all documentation. * The Information Security Officer is responsible for the development and maintenance of all ISMS documentation. * The Information Security Officer shall schedule periodic internal audits with the help of either the internal team or external consultants. * The Information Security Officer, along with the Head of Engineering, is responsible for building a strategic and comprehensive privacy program that defines, develops, maintains, and implements policies and processes that enable consistent, effective privacy practices thatwhich minimize the risk and ensure the confidentiality of Personally Identifiable Information (PII), paper or electronic, across all media types. ## 16 Schedule This document is to be reviewed annually and whenever significant changes occur in the organization. # Media Disposal Policy ## 1 Objective Secure disposal of electronic and physical media adds a layer of protection to prevent critical data from being exposed to unauthorized individuals. This policy aims to mitigate the risk of unauthorized data recovery. It demonstrates to customers, \ staff, and other partners that \ protects their data even after it has fulfilled its purpose. ## 2 Scope This policy applies to all \ issued devices or equipment that process, store, transmit, or serve as an access point for any critical data. Specifically, it applies to company-issued laptops/workstations that are being permanently decommissioned. ## 3 Policy Statement To securely dispose of company-issued laptops/workstations, the following steps can be followed: * Encrypt the entire hard disk using a robust algorithm and a lengthy password. * Securely delete all information by using software solutions. * Physically destroy the device through methods such as incineration or shredding. * It is recommended to use all three methods for extremely critical and sensitive data. * For data with lower levels of criticality, one of these methods is sufficient. ## 4 Document Security Classification Company Internal (please refer to the Data Classification policy for more details). ## 5 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 6 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 7 Schedule This document shall be reviewed annually and whenever significant changes occur within the organization. # Vendor Management Policy ## 1 Objective \ depends on third-party vendors for a range of services. Some of these services are critical for \ to meet its security commitments and provide uninterrupted services to its customers. This policy provides the guidelines for managing vendor relationships that affect the services we provide with an aim to minimize the risk associated with using third parties. ## 2 Scope This policy applies specifically to vendors whose services are critical to the operational integrity and availability of \'s services to its customers or with whom critical data is shared. ## 3 Policy Statement \ is committed to exercising caution when sharing critical data with third-party vendors. It is essential to recognize that each instance of data shared with a vendor expands the potential attack surface of that data. Given our reliance on multiple third-party services, there is a need to share specific data. This policy establishes a deliberate process for evaluating critical third-party vendors, ensuring we maintain the highest data security and risk assessment standards. ## 4 Vendor Management ### 4.1 Information Security in Vendor Relationships * Information security requirements for mitigating the risks associated with the vendor’s access to \’s assets shall be agreed upon with the supplier and documented in the form of agreements or contracts. * Resilience and, if necessary, recovery and contingency arrangements to ensure the availability of the information or information processing provided by either party shall be defined within these agreements or contracts. * For third-party personnel who have access to \’s assets, it is essential that they acknowledge the latest version of \’s information security policies. * Security controls and service levels specified in the contracts or agreements shall be implemented, operated, and maintained by the vendor. * Contracts/Agreements shall include information security requirements to ensure compliance with \’s security policies and procedures. * Non-Disclosure / Confidentiality agreements to protect \’s information assets shall be signed by vendors, third parties, contractors, and subcontractors of the vendors, as applicable. ### 4.2 Vendor Risk Assessments and Service Delivery Reviews * A list of all vendors - critical to \’s services and vendors with whom critical data is shared – needsneed to be maintained. * For each vendor in the list, a vendor assessment shall be performed, and their risk/criticality to \’s services and sensitivity of data shared. * Where required, \ may also perform reviews of vendor’s services through periodic review calls or audits of vendors. Please note that this may only be required in extreme cases. 3. ### Review Vendors and Managing Changes to Vendor Services * Periodic reviews of the list of vendors and their risk assessment shall be performed at least annually. * It is the responsibility of the managers of business functions always to keep the Information Security officer informed of any changes in vendors or the level of service that a particular vendor is providing. * All such changes shall be accompanied by a review or update of the list of vendors as applicable and a re-assessment of risks. ## 5 Document Security Classification Company Internal (please refer to the Data Classification policy for more details). ## 6 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 7 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 8 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization.
# Asset Management Policy ## 1 Objective The objective of this document is to provide a framework to ensure that \’s information assets and data are protected and handled appropriately. ## 2 Scope This policy shall be applicable to assets used across all processes and operations within the scope of the ISMS at \. ## 3 Policy Statement The Asset Management Policy is established to ensure that all \ assets are classified and appropriately protected and that information handling or exchange of information is in accordance with this classification. This shall prevent unauthorized disclosure, modification, removal, or destruction of assets and interruption to business activities. ## 4 Asset Management ### 4.1. Types of Assets The following are examples of the types of assets that need to be considered as Information Assets: * Infrastructure Assets: databases and data files, servers, and version control systems. * Software Assets: application software, system software, development tools, and utility software. * Physical Assets: computer equipment, communications equipment, removable media, and other equipment. * Service Assets: computing and communications services, general utilities such as heating, lighting, power, air-conditioning, and third-party suppliers. * People Assets: employees (full-time and part-time), customers, contractors. * Paper Assets/E-Documentation: contracts, agreements, non-disclosure agreements, system documentation, user manuals, training material, operational or support procedures, business continuity plans, fallback procedures, audit trails, and archived information. ### 4.2. Responsibility of Assets * All information and associated assets shall have an individual or department with management responsibility assigned to control the production, development, maintenance, use, and security of the information asset. * Each asset shall have an Asset Owner and, if required, a nominated custodian who may be different from the Asset Owner. * The owner shall be responsible for the following: * Ensuring that information and assets associated with information processing facilities are appropriately classified. * Defining and maintaining the security of the assets along with helping the Information Security Officer periodically review access restrictions and classifications, taking into account applicable access control policies. * As information is important and pervasive throughout \, all users have an important role and a responsibility to protect the information entrusted to them. All users who may come into contact with sensitive information (non-public) are expected to familiarize themselves with the Asset Management Policy and the Asset Management Procedure. ### 4.3. Inventory of Assets * At all times, the updated inventory of assets shall be maintained. * There should be owners assigned to maintaining the asset inventory. The owners may be different based on the type of asset. * At the minimum, the inventory of assets needs to include an asset ID, an asset classification, and an asset owner. ### 4.4. Acceptable Use of Assets * Acceptable use of assets associated with information assets shall be clearly defined. * All users (employees and contract partners) who use or interface with assets associated with \ shall acknowledge their awareness of the acceptable use of assets. ### 4.3. Return of Assets Upon termination, \ employees and contract partners shall return / hand over all the organization's information assets under their purview. ## 5 Data Classification * Information assets shall be classified based on their business value, legal requirements, sensitivity, and criticality to the organization. * It is important to understand the type of data the information asset processes to ensure that assets are handled appropriately. Please refer to the Data Classification Policy for more details. ## 6 Management of Removable Media Usage of removable media such as a USB or hard drives to transfer data shall be prohibited. Any such use shall be deemed as non-compliance with this policy. ## 7 Disposal of Media * Disposal of media, both electronic and physical, is important to ensure that data is protected from exposure to unauthorized people. * Media shall be disposed of securely, following the formal guidelines when no longer required. The level of destruction or disposal of media would depend on the information or data stored in the media and the criticality of the information as per the Data Classification policy. * Please refer to the Media Disposal policy for guidelines and details. ## 8 Document Security Classification Company Internal (please refer to the Data Classification policy for more details). ## 9 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 10 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 11 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization.
# Compliance Policy ## 1 Objective The purpose of this policy is to establish guidelines for the management of regulatory and legal compliance requirements for systems in accordance with applicable standards such as ISO 27001:2013, ISO 27001:2022, SSAE 18(SOC 2), and other standards. ## 2 Scope This document is applicable to all \’s processes and operations that are within the scope of the Information Security Management System (ISMS) (refer to the definition in Section 3 of the Information Security Policy). ## 3 Policy Statement The information security management system of \ shall be established and operated with due consideration for compliance with statutory, regulatory, or contractual obligations as well as any specific security requirements. ## 4 Compliance Policy ### 4.1 Identification of Applicable Legislations & Compliance Requirements All relevant statutory, regulatory, and contractual requirements of the operations shall be explicitly defined and documented for \’s information systems. The policies and procedures shall encompass and adhere to the applicable laws where applicable. Documentation of the requirements is mandatory only for ISO 27001. For other standards, ensuring compliance with the applicable requirements must be taken into account, but explicit documentation is not required. ### 4.2. Intellectual Property Rights \ shall comply with the terms and conditions and license requirements of copyrighted software, client intellectual property, or any other proprietary information used within the organization. * ### Protection of Organizational Records \’s records related to information security shall be protected from loss, destruction, and falsification in accordance with statutory, regulatory, contractual, and business requirements. * ### Data Protection & Privacy of Personal Information Data protection and privacy shall be ensured as required by relevant legislation, regulations, and if applicable, contractual clauses for each business * ### Prevention of Misuse of Information Processing Facilities Information processing facilities shall be used in accordance with the policies detailed in this document, the Acceptable Usage policy, and the Code of Business Conduct policy. Disciplinary action shall be taken for any violations of these policies * ### Compliance with Security Policies, Standards & Technical Compliance Department heads shall ensure that all security procedures within their area of responsibility are correctly carried out to achieve compliance with security policies and standards * ### Information Systems Audit Considerations \ shall conduct periodic audits by competent, independent parties to ensure compliance with information security policies, procedures, standards, and guidelines. Formal procedures shall be developed for planning and reporting audits, as well as addressing audit findings and implementing prompt and accurate remedial actions. * Audit requirements and activities involving checks on operational systems shall be carefully planned and agreed upon to minimize the risk of disruptions to business processes. * Access to information systems audit tools shall be protected to prevent any possible misuse or compromise. ## 5 Document Security Classification ​​Company Internal (please refer to the Data Classification policy for more details). ## 6 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 7 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 8 Schedule This document shall be reviewed annually and whenever significant changes occur within the organization.
# Operation Security Policy ## 1 Objective The objective of this policy is to provide guidelines to ensure the secure processing of \’s production infrastructure and ensure there are no disruptions to the availability of \’s services through adequate planning, operating procedures, back-up, change management, logging, and vulnerability management. ## 2 Scope This document is applicable to all processes and operations in \ within the scope of the ISMS. ## 3 Policy Statement \ shall take adequate precautions and design appropriate controls to prevent misuse of its information assets and ensure that any operational activities at \ do not affect the confidentiality, integrity, and availability of \’s services. In this regard, \ shall ensure to maintain the appropriate level of information security, minimize risks of system failures, protect the integrity of software and information, maintain the integrity and availability of information, protect information in networks and infrastructure, prevent unauthorized disclosure, manage technical vulnerabilities, maintain security of information and software exchanged and detect any unauthorized activities. ## 4 Operations Security Policy ### 4.1 Change Management * Formal change management procedures shall be established to ensure controlled changes of all critical elements that affect information security which may include but are not limited to software, production infrastructure, network devices, configurations, and documented policies and procedures. * It is recommended that the procedure should consider how to handle scheduled and emergency changes. * All changes shall be recorded, approved, and tested before being implemented. * It is essential to have all the changes, along with approvals, recorded in centralized systems like version control systems or ticketing tools. * The requestor, reviewer/approver, and implementer's responsibilities for addressing the change shall not rest with the same user to ensure segregation of duties. * Changes should be tested in an isolated, controlled, and representative environment (where such an environment is feasible) prior to implementation to minimize the effect on the relevant business process, assess its impact on operations and security, and verify that only intended and approved changes were made. * The production environment shall be separated from other environments to reduce the risks of unauthorized access or changes to the operating system. * Modifications to vendor-supplied products should be discouraged. Vendors must be intimated if a change is warranted to obtain system patches/releases and ensure that security and functionality features are not impacted. The original software shall be retained, and changes shall be documented. ### 4.2 Capacity Management * Critical parameters and their thresholds shall be monitored for all critical infrastructure elements and software(s) at periodic intervals to ensure required performance levels and availability. * Capacity planning shall take into account current and projected trends in the organization’s information-processing capabilities. * System monitoring shall be enabled to ensure and, where necessary, improve the availability and efficiency of systems. Detective controls like alerts or alarms shall be put in place to indicate problems in due time. ### 4.3 Configuration Management * Configuring baselines for critical infrastructure and software should be established and documented where required. Such baselines include server hardening, end-point device hardening, firewall, and network device configurations. It is the decision of the organization whether such documentation is required or not. * Any change to existing configurations of all production infrastructure, network devices, and firewall configurations must always follow the change management process and must be approved before such configuration changes are made. * If the baselines are documented, any change must be approved and appropriately documented. It is recommended to follow the change management process for such a change. * Clock synchronization configurations should be taken care of across all cloud infrastructure, cloud services, and endpoints. It is recommended to ensure they are synced depending on time zones to ensure that integrity and traceability of data are maintained. ### 4.4 Backups * All original customer data on the infrastructure operated by \ should be backed up. * The frequency of such backups should be decided based on the risk considered to the organization and service level commitments made to customers and stakeholders. * A backup restoration exercise must be performed to ensure that the backup data is readable and usable in case of any emergency or disaster. * Backups must be stored at a redundant location outside the production environment itself. The number of such redundant locations should be decided based on perceived operational risks. * In case \ has any on-premise production servers and data, if required, appropriate procedures to take backups on physical media and a procedure to store it at offsite locations must be considered to minimize risks. * Relevant documented processes/procedures shall be created and followed to meet the business requirements. The process/procedures shall be defineddefine as follows: * Frequency for taking backup and testing of backup through a restoration process. * Data to be backed up. * Type of backup (incremental, differential, full). * The testing procedure for ensuring that the backup media can be relied upon in an emergency. Backup data shall be periodically restored, and the results be recorded. If the restoration test fails, the data owner should be notified regarding the same. Root cause analysis for such failure should be carried out. * Instructions to restore in case of an actual disaster. * The retention period for backup. ### 4.5 Logging and Monitoring * Infrastructure elements and software used for \’s operations should be configured, where feasible, to capture security-relevant logs (e.g., use of privileged accounts like root and administrator accounts, system failures, policy violations, unauthorized access attempts, logging of firewall traffic). * Such monitoring and logging activities shall also consider information requirements for logging prescribed under legal and contractual requirements, if any. Evidence shall be collected, retained, and presented where legal actions are required following an information security incident or regulatory information provision. * Logs shall be securely maintained for a minimum period stipulated as per applicable laws and regulations to provide support for investigations of incidents. * Logging facilities and log information shall be protected against tampering and unauthorized access. ### 4.6 Control of Operational Software \ does not allow the installation of any other software on our production infrastructure. ### 4.7 Technical Vulnerability Management * There shall be a documented procedure for technical vulnerability management. * Timely information about technical vulnerabilities in infrastructure elements and software(s) being used shall be obtained from trusted sources. * Where possible, tool-based vulnerability scans shall be carried out for all critical infrastructure elements and software(s). * Once every year, it is recommended to have a vulnerability assessment performed by a 3rd party vendor. * Timelines shall be defined for responding to identified/reported technical vulnerabilities. * Information obtained regarding vulnerability shall be evaluated to assess risk to \’s infrastructure. The evaluation shall take into consideration the following: * Vendor/tool reported criticality (e.g., high, medium, and low). * Likelihood of the vulnerability being exploited (e.g., the existence of a known exploit or other malicious code that uses the vulnerability as an attack vector). * The identified risk shall be categorized as per the severity of the risk (e.g., High, Medium, and Low). * If the vulnerability closure requires patch deployment, the patch must be tested in a test environment before deployment to the production environment. * The system shall be checked to verify if the patch has not affected any of the existing functionality. * For high-risk vulnerabilities, after applying the patch/solution, a check shall be performed to ensure that the vulnerability has been closed. ## 5 Document Security Classification Company Internal (please refer to the Data Classification policy for more details). ## 6 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 7 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 8 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # Organization of Information Security Policy ## 1 Objective The objective of this document is to define an Information Security Management System (ISMS) governance framework within which the security organizational structure is identified, and information security roles, responsibilities, and authorities are assigned to ensure the segregation of duties. This policy is established to initiate and control the implementation of information security within the organization. ## 2 Scope This document is applicable to all processes and operations within \ that fall within the scope of the Information Security Management System (ISMS) (refer to the definition in Section 3 of the Information Security Policy). ## 3 Policy Statement The responsibilities for information security at \ will be clearly defined through job descriptions and task delegation. The Information Security Officer will approve the information security policy and standards. Responsibilities include identifying information assets, classifying them, implementing controls, and reviewing user access privileges. Segregation of duties and appropriate contact with authorities and special interest groups are emphasized. Information security will be integrated into project management, and precautions for mobile devices and teleworking shall be outlined. ## 4 Organization of Information Security ### 4.1 Information Security Roles and Responsibilities * All information security responsibilities related to the protection of \’s sensitive information, information systems, and information processing facilities shall be clearly defined through job descriptions, work allocation, and task delegation. * The Information Security Officer shall approve the information security policy. * The Information Security Officer shall approve the standards, procedures, templates, and guidelines. * The defined information security responsibilities shall be formally allocated and accepted across the organization. These responsibilities shall include: * Identifying the information assets and the security processes associated with each asset. * Defining and documenting the asset ownership, level of responsibility, and authorization levels. * Classifying, labeling, and handling information assets in accordance with \ Data Classification Policy. * Identifying and Implementing controls necessary to adequately protect assets. * Reviewing and approving user access privileges in accordance with the Access Control Policy & Procedure. ### 4.2 Segregation of Duties * Segregation of duties should be considered before assigning roles to carry out business activities to reduce opportunities for deliberate or accidental misuse of infrastructure elements or software. For example, the ability to initiate, authorize, execute, and verify requests should be split so that no one person completes the entire request. * Where segregation of duties is not possible, appropriate compensatory controls such as activity monitoring, audit trails, and management supervision shall be developed to detect misuse of access rights. * When primary personnel is unavailable due to illness, being on vacation, or due to leave of absence and another person with a different role fills in, appropriate segregation or compensatory controls shall be considered.
### 4.3 Contact with Authorities Appropriate contacts shall be established with law enforcement authorities, regulatory bodies, third-party vendors, hardware vendors, software vendors, and office security providers. ### 4.4 Contact with Special Interest Groups * The objective of this guideline is to ensure that \ maintains appropriate contact with special interest groups and authorized information security forums to receive and distribute updates on new vulnerabilities, security threats, regulations, or risks pertaining to its business. * The Information Security Officer at \ will ensure that contacts with Special Interest Groups are maintained in the interest of \’s security posture. The Information Security Officer shall consider maintaining contacts with the following types of special interest groups, but not limited to: * Special Security Forums: These forums enhance the security of communications and information infrastructure through proactive action and effective collaboration with other security bodies. These forums issue security guidelines and advisories and share information relating to the latest changes in information security. These forums help in reporting local problems. * Security Advisories: Security advisories provide objective, timely, and comprehensive information about security threats and vulnerabilities. An example could be certain security advisory websites. * Application Vendors/suppliers: Contacts with vendors/suppliers for applications used within the \ environment should be maintained to ensure that the latest threats and vulnerabilities applicable to these applications are addressed. * Other institutions that can help in solving security issues. * The Information Security Officer shall be associated with the above companies/institutions with the objective to: * Get updates on new vulnerabilities, security threats, and regulations pertaining to the telecom industry. * Improve knowledge and keep up-to-date with relevant security information. * Ensure that the understanding of the information security environment is current and complete. * Receive early warningz̄s of alerts, advisories, and patches pertaining to attacks and vulnerabilities. * Gain access to specialist information security advice. * Share and exchange information about new technologies, products, threats, or vulnerabilities. ### 4.5 Information Security in Project Management * Information security shall be integrated into \’ project management methods to ensure that information security risks are identified and addressed as part of projects. * Information security implications shall be taken care of regularly in all projects. ### 4.6 Mobile Devices & Teleworking #### 4.6.1 Mobile Device Policy * When traveling (in cars, hotels, conferences, meeting rooms, and public places), employees shall take reasonable precautions to protect their laptops as much as possible from damage, theft, and eavesdropping. If left unguarded, the laptop should be concealed as far as possible (e.g., locked in the trunk/boot of the car). Normally an unattended laptop should be in shutdown mode, and an unattended laptop should never be accessible without password protection. * The loss of a laptop/mobile device must be reported immediately to the HR Team or the Project Manager. * An employee may not make any alterations that circumvent the security mechanisms of \ for their laptop. In addition to disciplinary measures, the employee may also be charged for the costs incurred by \ if the laptop is damaged through unacceptable manipulation. Unacceptable manipulation includes, for example: * Autonomous set-up of unauthorized Internet connections. * Switching off the virus scanner, particularly with an open connection to the Internet. * Misusing privileges granted to enable certain business functions. * Users are responsible for maintaining the confidentiality, integrity, and availability of the information on their mobile computing devices. * The Information Security Officer shall ensure that all endpoints with access to the production infrastructure have antivirus software installed. #### 4.6.2 Teleworking * Employees shall take all necessary precautions to secure information and equipment in their homes, prevent unauthorized access to any system or information and comply with the ‘Acceptable Usage of Assets’ policy. * \'s equipment must be protected against damage and unauthorized use. Employees need to designate a safe workspace at home that is free from hazards. Safeguards should be applied to protect records from unauthorized disclosure or damage. Wherever applicable, all records, papers, and correspondence should be safeguarded for their return to the office. * Revocation of authority, access rights, and return of equipment should occur when teleworking activities cease or when the employee exits from \. ## 5 Document Security Classification Company Internal (please refer to the Data Classification policy for more details). ## 6 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 7 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 8 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # Physical & Environmental Security Policy ## 1 Objective The purpose of this policy is to establish the guidelines by which physical and environmental security is managed for ISMS scope systems. ## 2 Scope This document is applicable to all processes and operations in \ within the scope of the ISMS. ## 3 Policy Statement As a cloud-native company, \ relies on the physical security measures of various cloud service providers, including the infrastructure service provider, to secure and manage production systems and customer data. No production servers or customer data are hosted on-premises. However, office premises are still secured by following guidelines for visitors, clean desks, printing, removable media, shoulder surfing, and compliance with local laws. Remote workers must ensure device security, protect customer data confidentiality, and adhere to information security policies. ## 4 Physical Security Policy * \ is a cloud-native company, and all our production infrastructure, including data storage, should be secured and managed by our cloud infrastructure service provider. We must rely on the physical security measures adopted by cloud service providers to ensure the security, availability, and confidentiality of our production systems. * Further, no production servers or customer data should be hosted within our premises. As a result, the physical security of our office premises is not critical to ensure the security, availability, and confidentiality of customer data. * Hence the risk has been transferred to the infrastructure provider to ensure the security, availability, and confidentiality of \’s production systems and customer data. * Physical security of the premises where we work continues to be essential, and the following steps are taken to secure the same: * Visitors: \ staff may invite visitors to the office premises for business reasons or during pre-specified times for social reasons. In such cases, the staff members are responsible for the visitor’s actions and always need to escort their visitors. As a general principle, do not invite anyone you do not trust or know to the office. \ Staff members who spot unauthorized visitors should either ask the unauthorized person to leave or refer the issue to management. * Clean desk: Ensure that no classified customer data, security keys/passwords, etc., are written on whiteboards or unattended notepads, etc. * Printing: Printing of customer classified data, security keys, passwords, etc., is prohibited. * Removable media: Use of removable media to transfer sensitive customer data is not allowed on laptops used by \ staff to perform their work. * Shoulder surfing: \ allows you to work outside the office premises. Should you find yourself working from a public place (like a coffee shop or airport), you should be aware of shoulder surfing. * Local laws: We must abide by local laws regarding fire safety, display of licenses, etc. ## 5 Working Remotely \ Staff who work remotely should follow these rules: * When working remotely, the security of the device you use to perform your work is your responsibility. For instance, your equipment should be in your presence, screen locked, or be stored securely. * Please follow the organization’s endpoint protection and encryption standards for any equipment (company-providedcompany provided or otherwise) used to perform your work. * Protect the confidentiality, security, and privacy of our customers' data by ensuring that unauthorized people may not view, overhear, or otherwise have access to such data. For example, be aware of “shoulder surfing” when working in public places like coffee shops or airports. * All remote work must be performed in a manner consistent with \’s information security policies. ## 6 Document Security Classification Company Internal (please refer to the Data Classification policy for more details). ## 7 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 8 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 9 Schedule This document is to be reviewed annually and whenever significant changes occur in the organization. # System Acquisition & Development Lifecycle Policy ## 1 Objective The objective of this policy is to provide a framework to ensure that software development activities performed in \ are aligned with integrated information security considerations throughout the development lifecycle. \ is committed to developing robust systems which are reliable while ensuring that security is an integral part of information systems throughout all phases of acquisition, development, and maintenance. ## 2 Scope This document focuses on the development process for the software products developed or acquired by \. This document is to be followed by all \ employees, sub-contractors, and partners who participate, either wholly or partially, in the product development process. ## 3 Policy Statement \ shall ensure that security is integral to its information systems throughout all phases of the acquisition, development, and maintenance life cycle. Security should be considered at every stage of an information system’s life cycle (e.g., feasibility, planning, development, implementation, maintenance, retirement, and disposal) to: * Ensure conformance with all appropriate security requirements * Protect enterprise data throughout its life cycle of system development * Prevent the introduction of new risks when the system is modified * Ensure proper removal/disposal of data when the system is retired ## 4 System Acquisition, Development & Maintenance ### 4.1. System Development Life Cycle Security shall be considered and included in all phases of the Software development lifecycle, including Requirement analysis, Design, Development, Testing, Implementation, Operations, and Maintenance. ### 4.2. Requirement Gathering * Security and privacy requirements needed for the new product or application shall be defined at the requirements definition stage. * Legal and regulatory implications and security requirements related to confidential data collection and usage done by the proposed system shall be considered. * \ shall consider requirements for ensuring the reliability and availability of information systems. Where availability cannot be guaranteed using existing architecture, redundant components or alternative architectures should be considered. ### 4.3. System Design * It is important to identify threats and potential vulnerabilities early in the design phase of the software lifecycle. Areas of system misuse and ways in which protective measures could be bypassed shall be identified. * The operating environment, internal and external interfaces of the system, sub-systems and components, data input and output from these sub-systems, and how the components of the software work together should be identified. * Software shall be designed to operate with minimum privileges necessary. * Application permissions, privileges, and access controls shall be designed to strictly adhere to the user roles defined. ### 4.4. System Development * \ shall establish a separate development environment, which is physically and logically isolated from the production environment and shall appropriately protect the development environment. * During system development, developers shall be instructed to observe caution in the below areas: * Check the validity of incoming data * Check the validity of outgoing data * Adhere to memory management best practices * Secure practices during authentication and session management * Use best practices for errors and exception management * Source code shall be protected from unauthorized access and source code version shall be controlled using automated mechanisms ## 5. Security in Development & Support Processes ### 5.1. Secure Application Development Principles As a part of secure development principles, \ shall consider: * Best practices and latest libraries for each programming language used. * Security in the application version control and code repository. * Training developers on the secure coding aspects. * Ensure developers’ capability of avoiding, finding, and fixing vulnerabilities wherever possible. ### 5.2. Security Requirements for Information Systems * Changes to systems within the development lifecycle should be controlled by the use of formal change control procedures. * The introduction of new systems and major changes to existing systems should follow a formal process of documentation, specification, testing, managed implementation, and quality control. * This process should include an analysis of the impacts of changes and the specification of security controls needed. * This process should also ensure that existing security procedures are not compromised, and that support programmers are given access only to those parts of the system necessary for their work, and that formal agreement and approval for any change is obtained. * During change control procedures the following diligence is to be considered: * Ensuring changes are submitted by authorized users. * Reviewing controls and integrity procedures to ensure that they shall not be compromised by the changes. * Identifying all software, information, database entities, and hardware that requires amendment. * Identifying and checking critical code to minimize the likelihood of known security weaknesses. * Ensuring authorized users approve changes prior to implementation. * Ensuring that the system documentation is updated on the completion of each change, wherever applicable. * Maintaining version control for all software updates. * Maintaining a record of all change requests. * Ensuring that Standard Operating Procedures and user manuals are changed as necessary to remain appropriate, as applicable. * Ensuring that the implementation of changes takes place at the right time and does not disturb the business processes involved. * Testing of new software should be done in an environment segregated from both the production and development environments. The tests should include patches, service packs, and other updates. * Automated updates should not be used on critical systems as some updates can cause critical information systems to fail. * Where automatic updates are considered, the risk to the integrity and availability of the system should be weighed against the benefit of speedy deployment of updates. * Technical review of applications after operating platform changes. * When underlying operating platforms are changed, business-critical applications should be reviewed and tested to ensure there is no adverse impact on organizational operations or security. * As far as possible and practicable, vendor-supplied software packages should be used without modification. Where a software package needs to be modified, the following points should be considered: * The risk of built-in controls and integrity processes being compromised. * Whether the consent of the vendor should be obtained. * The possibility of obtaining the required changes from the vendor as standard program updates. * The impact if the organization becomes responsible for the future maintenance of the software as a result of changes. * Compatibility with other software in use. If changes are necessary, the original software should be retained, and the changes applied to a designated copy. * A software update management process should be implemented to ensure the most up-to-date approved patches and application updates are installed for all authorized software. * All changes should be fully tested, so that they can be reapplied, if necessary, to future software upgrades. If required, the modifications should be tested and validated by an independent evaluation body. ### 5.3. Secure Engineering * Security system engineering principles include security at all the architecture layers (business, data, applications, and technology), balancing the need for information security with the need for accessibility. * New technology should be analyzed for security risks and the design should be reviewed against known attack patterns. * Systems should be regularly reviewed to ensure that they remain up to date to address any new potential threats and be scalable. * Security engineering principles should be applied, where applicable, to outsourced information systems through the contracts and other binding agreements between the organization and the third party to whom the organization outsources. ### 5.4. Establishing Secure Development Environments * The Engineering Team should establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development life cycle. * A secure development environment includes people, processes, and technology associated with system development and integration. * Engineering Team should assess risks associated with individual Information system development efforts and provide requirements for secure development environments for specific system development efforts, considering: * Sensitivity of data to be processed, stored, and transmitted by the system. * Applicable external and internal requirements, e.g., regulations or policies. * Security controls already implemented by the \ that supportsupports information system development. * Trustworthiness of personnel working in the environment. * Degree of outsourcing associated with system development. * The need for segregation between different development environments. * Control of access to the development environment. * Backups should be stored at secure offsite locations. * Control over the movement of data from and to the environment. ## 6 System Testing * New and updated systems require thorough testing and verification during the development processes, including the preparation of a detailed schedule of activities and test inputs and expected outputs under a range of conditions. * For in-house developments, such tests should initially be performed by the Engineering Team. Independent acceptance testing should then be undertaken (both for in-house and for outsourced developments) to ensure that the system works as expected and only as expected. This testing should be performed before making the change in the production environment. * The extent of testing should be decided by the Engineering Team in concurrence with business requirements considering the importance and nature of the system. * The testing should also be conducted on integrated systems. The Engineering team can leverage automated tools, such as code analysis tools or vulnerability scanners, and should verify the remediation of defects. * Testing should be performed in a test environment to ensure that the Information system shall not introduce vulnerabilities to the \ environment and that the tests are reliable. ## 7 Test Data * The use of operational data containing personally identifiable information or any other confidential information for testing purposes should be avoided. * If personally identifiable information or otherwise confidential information is used for testing purposes, all sensitive details and content should be protected by removal or modification. * The following guidelines should be applied to protect operational data when used for testing purposes: * The access control procedures, which apply to production application systems, should also apply to test application systems. * Operational information should be erased from a test environment immediately after testing. * The copying and use of operational information should be logged to provide an audit trail. ## 8 Document Security Classification Company Internal (please refer to the Data Classification policy for more details). ## 9 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 10 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 11 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # Access Control Procedure ## 1 Objective The objective of this document is to establish a procedure and framework for user access management and controlling access to assets and information systems of \, in accordance with the Access Control Policy. ## 2 Scope This procedure applies to all users and administrators with access to any critical systems in \. ## 3 Access Control Procedure ### 3.1 Requirements for Access Control * A list of systems that are critical from an access control standpoint are listed and maintained in Sprinto App. \’s Iinformation Ssecurity Oofficer is responsible for maintaining this list up to date. * A list of all critical systems that require access control shall be made available in the Sprinto App in one of the following ways: * Integrated Systems – Where possible, the respective administrators of critical systems should integrate the system with Sprinto App for automated and continuous monitoring of access control requirements. Examples of such systems include cloud infrastructure providers (like AWS, Azure), version control systems (like Github, bitbucket), email providers (like Google Workspace, Microsoft O365), HRMS systems, etc. * Monitored Systems - Where iIntegrations are not possible, the critical systems should be added to Sprinto App for tracking and monitoring. Adding such systems to Sprinto App to ensure they are monitored is the responsibility of the Information Security Officer. * It is the responsibility of the Information Security Officer to ensure that the roles that can get access to each critical system are configured in the Sprinto App. ### 3.2 Access Provisioning * The access to \ systems should be initiated only after an offer letter, including the terms and conditions of employment, has been formally signed by the employee. * By default, all staff membersemployees get access to systems that are configured to be given to all staff. Examples include email providers or internal messaging tools. * Access to other systems should be assigned by respective system administrators based on the role matrix defined once the staff memberemployee has been onboarded. * Staff membersUsers who are not configured to have access to a particular system will be automatically monitored and alerted by Sprinto App. It is the responsibility of the Information Security Officer to respond to such alerts and ensure the role matrix is updated or the access is removed. * For iIntegrated systems, the Information Security Oofficer should ensure that User IDs created in the systems for each user are tagged to their respective company email IDs in Sprinto App to ensure users are identified and tracked continuously. * For access provisioning of third-party users (consultants, auditors, vendors/suppliers, etc.), Information Security Officer or Business heads should approve the access. For such users, the system administrator should make sure care should be taken by the system administrator to disable the account after the requirement is over. ### 3.3 Management of Privileged Access Rights * It is the responsibility of system administrators to ensure that the least privilege principle is followed when granting access. * As a part of access reviews, the Information Security Officer shall take the help of individual system administrators and business heads to review the privileges assigned to users. ### 3.4 Management of Secret Authentication Information of Users * Where possible, SSO and MFA need to be enabled to reduce reliance on passwords. * For critical systems which are integrated with the Sprinto App, it is the responsibility of the Information Security Officer to ensure the MFA status for users with access to systems is monitored continuously on the Sprinto App. * In case of discrepancies alerted by Sprinto App, the Information Security Officer should ensure corrective actions are taken immediately. * For mMonitored sSystems, the Information Security Officer should make sure that secure login/password management is enabled and that the evidence for it is uploaded on Sprinto App. ### 3.5 Review of Access Rights * Access reviews should be carried out once every quarter by the Information Security Officer with help from respective system administrators for all production systems. For non-production systems, access reviews should be carried out at least annually. * The access review for critical systems should be completed within the Sprinto App where possible. For all monitored systems, evidence of performing reviews needs to be uploaded to the Sprinto App. * Any corrective step that needs to be taken in case of discrepancies noted should be documented as a part of the access review activity. * Review of access rights should also include reviews of privileges assigned to individual users to ensure segregation of duties. ### 3.6 Removal or Adjustment of Access Rights * In case of any termination or change in role, the HR team should inform the system administrators and respective managers to revoke or modify access. * On termination of employment, access revocation from all critical systems should be completed within three days from the employee’s last working day. * In case of a change in role, the HR team should check and ensure that the roles assigned to the employee in Sprinto App/HRMS are valid or if theyit needneeds to be updated. They should notify respective administrators and managers immediately to update the access if required. The HR team should also notify the Information Security Officer to update the role-based access matrix. ### 3.7 User Responsibilities * Users are responsible for following the organization’s access control policy and procedure. * Users are responsible for keeping their passwords confidential. * Users are responsible for changing the passwords whenever there is any indication of possible system or password compromise. * Incidents relating to passwords/personal authentication information sharing should be reported via the Employee Portal in the Sprinto App. * Users shall not leave their system unattended while logged on. They shall lock the system even if they are moving away from the system for a short period of time. ## 4 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 5 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 6 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 7 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # Asset Management Procedure ## 1 Objective The objective of this document is to describe a formal procedure to be followed for maintaining, handling, and protecting all the information assets of \. ## 2 Scope This procedure applies to all the employees at \ who use or have access to \’s information assets and data. ## 3 Asset Management Procedure ### 3.1 Inventory of Assets * At all times, the updated inventory of assets shall be maintained. * A list of information assets like infrastructure, code repositories, software, and people assets are automatically maintained using cloud service providers, version control systems, identity providers, or HRMS applications (if applicable), respectively. * For assets where inventory cannot be maintained automatically, it is the responsibility of the Information Security Officer to document the use of other software assets that have access to sensitive information. * \ allows employees to bring their own laptops or \ issued laptops in some cases. For all such end-point devices, employees are responsible for reporting the device that they use to access \’s data. The guidelines to maintain the security of endpoint devices shall be made available to all users through the Endpoint Security Policy. * It is the responsibility of the People Operations Head to ensure that all employees have reported the status of devices used by them. * The inventory of assets should also include the asset owner. Asset owners shall be responsible for maintaining and updating the inventory of the assets. * The Information Security Officer or Infra Operations Person must verify the information asset inventory once it is created and at least on an annual basis thereafter. ### 3.2 Managing Infrastructure Assets * Any new infrastructure asset acquired by \ should automatically be tracked in the inventory that is maintained. In case it is not tracked automatically or in the event of a non-success, the Infra Operations Person or Information Security Officer must ensure the asset list is updated periodically. * The Infra Operations Person is responsible for the classification of all infrastructure assets. The classification scheme is based on the type of data that the assets process and their criticality to services. The classification should be based on the Data Classification Policy. * Based upon the classification of assets, there are security controls implemented to safeguard the integrity of the asset. These security controls are tracked along with the inventory of assets. * The status of the security controls is automatically monitored through tools that integrate with cloud service providers/version control systems. * If any of the security controls fail, an automatic alert is sent to the Infra Operations Person, who will be responsible for implementing the necessary changes promptly. * If the controls are not implemented within the stipulated time, the security gaps are escalated automatically to the Information Security Officer, who will need to take necessary rectifying measures. ### 3.3 Managing End Point Assets * \ allows employees to “Bring your own device” for their company operations. The list of all the end-point devices is maintained. * All employees need to report the devices that they use to access \’s data. * If maintained manually, it is the responsibility of the Information Security Officer to ensure that periodic requests are sent at least once a quarter to all employees to report their device security status. * It is the responsibility of users to follow the recommended steps below to ensure the security of endpoints: * \ staff is responsible for installing critical firmware and software updates on the endpoints they use or where they’re the assigned owner. * \ requires that all endpoints with access to critical data to use antivirus software to protect from malware. * \ requires that all endpoints with access to critical data to turn on the hard disk encryption option of their respective operating systems (ex: FileVault on Mac). * As detailed in the access control policy, \ staff members should use strong passwords to protect against unauthorized access to their system or any services they use. While it is not mandatory, it is recommended to use a password manager. * \ requires that all endpoints with access to critical data to have auto-screen-lock on their systems within a reasonable amount of inactive period. While the screen lock will protect the device in most cases, it is recommended not to leave the computer unattended and unlocked. * Employees must immediately report lost, stolen, or damaged devices to the \ management, which will then attempt to constrain access to production systems and customer data through the exposed device. * Employees must follow the removable media guidelines outlined in the Asset Management and Physical and Environmental Security policies. * Endpoints may be verified for compliance with this policy through various methods, including but not limited to periodic reviews, automated monitoring, and internal and external audits. ### 3.4 Review of Assets The Infra Operations person and the Information Security Officer must review the list of Infrastructure assets and critical systems at least annually. ## 4 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 5 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 6 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 7 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # Business Continuity Plan ## 1 Objective The objective of this business continuity plan is to prepare \ in the event of extended service outages caused by factors beyond our control (e.g., natural disasters, man-made events), and to restore services to the widest extent possible within an acceptable time frame. ## 2 Scope The scope of this plan is limited to business continuity and disaster recovery of \’s production infrastructure. ## 3 Plan Objectives * Serves as a guide for the recovery teams of \. * References and points to the location of critical data. * Provides procedures and resources needed to assist in recovery. * Identifies vendors and customers that must be notified in the event of a disaster. * Assists in avoiding confusion experienced during a crisis by documenting, testing, and reviewing recovery procedures. ## 4 Assumptions * Key people (team leaders or alternates) will be available following a disaster. * A national disaster such as a nuclear war is beyond the scope of this plan. * This document and all vital records are stored in a secure off-site location and not only survive the disaster but are accessible immediately following the disaster. * Each support organization will have its own plan consisting of unique recovery procedures, critical resource information, and procedures. ## 5 Disaster Definition Any loss of utility service (power, water), connectivity (system sites), or catastrophic event (weather, natural disaster, vandalism) that causes an interruption in the service provided by \ operations. The plan identifies vulnerabilities and recommends measures to prevent extended service outages.
## 6 Preparation for Disaster Recovery & Business Continuity * It is essential that frequent backups are taken, and backups are stored at a redundant location to facilitate restoration in case of a disaster. * A backup restoration exercise should be performed by the Infra Operations Person with help from the engineering team. * The Information Security Officer should ensure that a disaster recovery mock drill is conducted by the Engineering team, which will then allow them to invoke this plan effectively. This exercise may be a tabletop exercise based on the availability commitments. * If required, through the disaster recovery exercise, the Engineering team should evaluate the following: * Recovery time objective * Recovery point objective ## 7 Instructions for Using the Plan #### 7.1 Invoking the Plan This plan becomes effective when a disaster occurs. #### 7.2 Disaster Declaration The Information Security Officer and/or Engineering Head is responsible for declaring a disaster and activating the various recovery teams as outlined in this plan. In a major disaster situation affecting multiple business units, the decision to declare a disaster will be determined by senior management. The Engineering Team will respond based on the directives specified by senior management. #### 7.3 Plan Review & Maintenance This document and the disaster recovery mock drill must be reviewed at least once annually. #### 7.4 Notification of Incident/Disaster * In cases of technical incidents, the Infra Operations Person/On-Call Engineer personnel should contact the Information Security Officer. * For any operational incident, it is the responsibility of the user/employee to report it as soon as possible through the Sprinto App and/or other means like e-mail or telephone, as applicable. * The Information Security Officer should be notified promptly when any of the following conditions exist: * Any server is down for three or more hours. * Any problem at any system that would cause the above condition to be present or there is a certain indication that the above condition is about to occur. * The Information Security Officer should contact the respective \ Business heads and report that a disaster has taken place. * Once a disaster has been declared, it must follow the incident management procedure and change management procedures while trying to bring back the availability of services. * Declare a disaster only if the situation is not likely to be resolved within predefined time frames. The person who is authorized to declare a disaster must also have at least one backup person who is also authorized to declare a disaster in the event the primary person is unavailable. * It is the responsibility of the Information Security Officer to ensure the event of a disaster and the successful recovery are communicated to relevant stakeholders, customers, and regulatory bodies as applicable. ## 8 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 9 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 10 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 11 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # Compliance Procedure ## 1 Objective The objective of this procedure is to establish the methods by which management of regulatory and legal compliance requirements for the systems which are in the scope of the Information Security Management System (ISMS) that is implemented. ## 2 Scope This document is applicable to all processes and operations in \ within the scope of the Information Security Management System (ISMS) (refer to the definition in Section 3 of the Information Security Policy). ## 3 Compliance with Legal Requirements ### 3.1 Identification of Applicable Legislation * The Information Security Officer, along with the Legal team and the Engineering team, should be responsible for the identification of any legislation that might have an impact on the policies and procedures laid down. They should be guided by the CEO. * Information Security Officer should update the applicable legislation as a part of the Information Security Manual and the associated procedures (Applicable and Mandatory only ISO 27001 is implemented). * Advice on statutory, regulatory, and contractual requirements of \ should be sought from the Engineering Team and the Legal team. * The Information Security Officer, along with other relevant teams, should also ensure that all the required controls are implemented to ensure compliance. * Regular periodic reviews of the compliance should be carried out by the Engineering team in conjunction with the Information Security Officer. ### 3.2 Data Protection & Privacy of Personal Information * Data protection and privacy should be ensured as required in the identified relevant legislation, regulations, and applicable contractual clauses. * The identified relevant legislation, regulations, and applicable contractual clauses should be communicated to all persons involved in the processing of personal information. * The Information Security Officer should provide the necessary guidance to the Business Heads on their individual responsibilities and the specific procedures that should be followed. * Any access to personal information should be on a “need-to-know” basis. ## 4 Safeguarding Organizational Records All organizational records shall be managed in accordance with the Data Classification Policy. ### 4.1. Prevention of Misuse of Information Processing Facilities Information processing facilities are to be used in accordance with the Acceptable Usage Policy. ## 5 Independent Reviews of Compliance with Security Policies & Standards * Compliance with the following policies and procedures shall be continuously monitored: * Human Resources Security * Asset Management * Physical and Environmental Security * Communications and Operations Management * Systems Acquisition, Development, and Maintenance * Supplier Management * Access Control * Network Security * Security Incident Management * Compliance * The Information Security Officer should ensure that all security procedures are appropriately tracked in accordance with the defined procedures. * The HR team should be responsible for educating employees regarding the security policies and associated procedures. * Each department should regularly review the status of compliance within its area of responsibility. If any non-compliance is found as a result of the review, managers should: * Determine the causes of the non-compliance. * Evaluate the need for actions to ensure that non-compliance does not recur. * Determine and implement appropriate corrective action. * Inform the Information Security Officer if required. * Information Security Officer should conduct a review once a year of all areas to ensure compliance with security policies and procedures. ## 6 Technical Compliance Checking One annual technical assessment and review should be performed by a competent third partythird-party along with the Engineering team to identify any potential vulnerabilities in the networks and other production systems. The findings of the assessment shall then be reported to the Information Security Officer. ## 7 Intellectual Property Rights Care must be taken by the Engineering team and the Information Security Officer that all third-party software and services are appropriately licensed and do not violate any copyrights or intellectual property rights. ## 8 Information Systems Audit ### 8.1. Preparing & Conducting Audits * While \ has implemented an automated compliance monitoring tool that performs continuous monitoring of the control environment and effectiveness of adherence to policies and procedures, there should be an annual audit performed of the control environment to ensure compliance is maintained. The key things to consider in this audit are: * Completeness of inventory of assets and systems. * Adherence to procedure SLAs. * Review of the list of vendors. * Review of Information Security Risks. * The audit may be performed by the Information Security Officer or an independent internal auditor, and the results must be communicated to the Senior management and should be reviewed by the senior management at least annually. ### 8.2. Audit Reports, Findings & Non-Conformance Closures * The auditors should perform the audit and record the non-conformances and their observations/ suggestions in the Internal Audit Report. * Any corrective actions that need to be taken must be documented in a corrective and preventive action (CAPA) register. * The internal audit report, along with the CAPA register must be presented to the senior management for their review. * The respective departments or functions should initiate corrective and preventive action on the non-conformances and close them within the committed closure time. * At the end of the committed time frame, the Information Security Officer should verify the closure of the non-conformances. ## 9 Corrective & Preventive Actions (Applicable & Mandatory Only if ISO 27001 is Implemented) The process for corrective/preventive action should be initiated whenever a condition warrants an investigation to determine if corrective or preventive action is required. ### 9.1. Corrective Actions * Corrective action should be documented using the Corrective Actions, and Preventive Actions Register (CAPA Register) if a non-conformance is raised during the internal audit. Corrective action should be initiated as a result of, but not limited to, the following: * Non-conformances identified during internal audits or external audits. * Action items from management reviews of information security effectiveness. * Reported security incidents. * Reported deviations in the provision of services. * Problems identified by employees pertaining to security weaknesses. * Violation of security policy and security objectives. ### 9.2. Preventive Actions * The Information Security Officer should maintain a summary of the corrective and preventive actions taken. (The corrective and preventive action details should be maintained in the same summary sheet). * Preventive action should be determined from the analysis of appropriate data to detect trends and identify causes that may result in future non-conformances. * The Information Security Officer should verify the effectiveness of corrective/preventive action taken for the concerned departments. * The results of corrective/preventive actions should be reviewed by the Senior Management during the meeting with the Information Security Officer. ## 10 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 11 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 12 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 13 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # HR Security Procedure ## 1 Objective This procedure specifies the information security requirements that should be considered throughout the various stages in the Human Resource lifecycle of employees (full-time and part-time) and external parties, including contractors and other third-party staff, (as applicable), including pre-employment, during employment, and at the end of employment. ## 2 Scope This procedure applies to all employees (full-time and part-time) and external parties, including contractors and other third-party staff (as applicable), having access to \ information systems. ## 3 HR Security Procedure ### 3.1. Before Employment * Before releasing the offer letter, the People Operations Head must ensure that potential employees are duly evaluated on their capability to perform the job role. This shall be documented as a hiring evaluation and are maintained after the employee has joined \. * The People Operations Head should ensure that the offer letter which includes the terms and conditions for the employees has been signed by the employee. * The People Operations Head must ensure that the Background Verification (BGV) of employees is initiated at the time of the joining and that the final Background Verification reports are documented and maintained. ### 3.2. During Employment * Once the employee has joined, the People Operations Head must ensure that the user has been onboarded onto all necessary tools and systems, granting them appropriate access as required. * After an employee joins, People Operations Head must assign them a role and reporting manager to make sure the organization chart is updated and documented. The list of active roles within the organization and their job description also needs to be documented and maintained. * The People Operations Head should make sure that the new joiners read and acknowledge organizational policies within 30 days of joining. * Employees must also finish the information security awareness training. The status should be tracked, and the HR head must make sure that Employees finish the training within 30 days of joining. * The Information Security Officer or the People Operations Head should send out periodic training requests and policy acknowledgment requests to all employees at least annually. The status of completion can be tracked, and it is their responsibility to ensure all employees finish the periodic activities. * Employees shall be evaluated by their reporting manager regarding their job and information security responsibilities atleast once annually. These evaluations also need to be documented and maintained. ### 3.3. Termination or Change in Employment * Once an employee decides to terminate his employment with \, the last working day must be decided in concurrence with the reporting manager and the People Operations Head. The following processes need to be kickstarted on the last working day: * The HR team must ensure any company-owned asset or device is returned to the organization. * The user needs to be offboarded from all critical systems that they have been provided access to by the People Operations Head. * Access to critical systems must be revoked within 3 days. The respective administrators need to be notified by the People Operations Head. The status can be tracked and monitored. * In case any user access needs to be retained, HR must notify respective admins to change the password to such accounts and document the justification for the same. ## 4 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 5 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 6 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 7 Schedule This document should be reviewed annually and whenever significant changes occur in the organization. # Incident Management Procedure ## 1 Objective The objective of this document is to establish a consistent and effective approach to the management of incidents throughout their lifecycle - from identification, assessment, corrective actions, and closure. ## 2 Scope This document is applicable to all staff members at \ performing various operations within the scope of the Information Security Management System (ISMS) (refer to the definition in Section 3 of the Information Security Policy). ## 3 Information Security Incident Management ### 3.1. Responsibilities * An Infra Operations person shall be appointed for: * Investigation/coordination of the reported Information Security incidents and Security weaknesses. * Tracking closure of incidents and, if required, ensuring identified corrective and preventive actions are taken. * It is the overall responsibility of the Infosec officer to ensure that any incidents are dealt with appropriately. ### 3.2. Reporting Information Security Events and Incidents * Where feasible, monitoring mechanisms are set up in \ for proactive monitoring of intrusions, attacks, and frauds. * Incidents at \ can be reported in two ways: * Automated Threat Detection Services such as AWS Guard duty - Such services monitor the infrastructure account and workloads for potential threats to the network. It shall analyze all relevant logs, including but not limited to system, network, performance, and application logs. If any threats or anomalous are detected, the findings will automatically be reported as incidents into a company-managed portal where they are tracked for investigation. * Staff Reported incidents – If any incident or security weakness is observed by employees during the course of operations must be reported. This communication portal shall be made available to all employees at all times. * In case any employee notices any malicious behavior by a \ staff member or partner, they should inform this incident directly to the Information Security Officer or the CEO. In such cases, they are strongly recommended to not discuss the issue with any other employee. * A log of all security incidents reported shall always be maintained. ### 3.3. Responding to Security Incidents * At any given point in time, the on-call engineerOn-Call-Engineer (OCE) is the first point of contact and is responsible for addressing the incident. Among other things, their responsibility to identify the severity of the incident as per the definitions below: * Low severity Incidents are those that do not require immediate remediation. These typically include a partial service of \ being unavailable (for which workarounds exist). These do not require someone to be paged or woken up beyond normal work hours. * Medium severity incidents are similar to Low but could include scenarios like suspicious emails or unusual activity on a staff laptop. Again, these do not require immediate remediation or trigger automatic calls outside work hours. Low and medium-severity incidents usually cover the large majority of incidents found. * High-severity incidents are problems an active security attack has not yet happened but are likely. This includes situations like backdoors, malware, and malicious access to business data (e.g. passwords, payment information, vulnerability data, etc.). In such cases, the Information Security Officer and the Engineering team must be informed, and immediate remediation steps should begin. * Critical severity incidents are those where a security attack was successful and something important was lost (or irreparable damage caused to production services). Again, in such cases, immediate actions need to be taken to limit the damage. * It is the responsibility of the On-Call engineer to notify the Infra Operations person, Information Security Officer, and any other relevant stakeholder immediately in case of any incidents that are classified as “High” or “Critical”. ### 3.4. Incident Response and Resolution * Once an incident is reported, a staff member or team will be assigned by the Infra Operations person to handle the incident. It is the responsibility of this person or team to investigate the incident and decide the appropriate response to the incident. * For all incidents where there was no data loss or direct impact on the availability of \’s services, the details of the investigation and corrective actions taken shall be documented as a part of incident closure notes. * For critical issues, the response team will follow an iterative response process designed to investigate, contain the exploitation, remediate the vulnerability, and write post-mortem and lessons-learned documents. Further, the following steps will be taken for critical incidents: * The ISO/CEO will determine if a lawyer should be involved with attorney-client privilege. * A staff member or team will be assigned to handle the incident. This person or team will be responsible for limiting the damage of the incident, bringing the system back to operational status, and updating the leadership on the status as required. * The team should create a timeline of known data related to the incident. The timeline should detail what we know the attacker did and at what times. * The team should also recommend long-term mitigations to suggest steps in order to avoid a similar crisis in the future. * In case of security incidents of specific kinds (like loss of data or data theft), the company leadership shall take steps to communicate with affected customers. ### 3.5. Learning from Critical Incidents * The analysis shall be carried out to determine the cause, effect, mitigation, and lessons learned for the Critical Information Security Incidents and shared with the management of \ and appropriate authorities. * Knowledge gained from the resolution of such incidents shall be documented and should be used to reduce the likelihood of similar incidents in the future and help limitwith limiting the impact of the incident. * The analysis should also consider, wherever possible, costs incurred due to information security incidents. * The output of the analysis shall be used to improve the security posture and to identify recurrence or impact tolerance. ### 3.6. Collection of Evidence * Where a follow-up action against a person or organization after an information security incident involves legal action (either civil or criminal), evidence shall be collected, retained, and presented to conform to the rules for evidence laid down in the relevant jurisdiction(s). * Before the seriousness/criticality of the incident is realized, due care shall be taken to ensure that necessary evidence/information is not destroyed intentionally or accidentally. ### 3.7. Contact with Authorities and Special Interest Groups * The Information Security Officer should maintain contact with external authorities, special interest groups, and forums (e.g., law enforcement, Cyber security team, customers) for information security incidents. * As per the applicable regulatory directives, the Information Security Officer should maintain contact with appropriate government authorities and report any incidents observed promptly. * Membership in special interest groups or forums should be considered as a means to: * Improve knowledge about best practices and stay up-to-date with the relevant security information. * Ensure the understanding of the information security environment is current and complete. * Receive early warnings of alerts, advisories, and patches pertaining to attacks and vulnerabilities. * Gain access to specialist information security advice. * Share and exchange information about new technologies, products, threats, or vulnerabilities. ## 4 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 5 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 6 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 7 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # Network Security Procedure ## 1 Objective Network security shall help minimize information security risk to a great extent and protect the organization against the threat of unintended information disclosure. \ networks (includes Cloud, VPC, and cloud services) must be protected from internal and external intrusion by designing network security at a level that is appropriate for the nature of data transmitted to protect all business data, related application systems, and operating systems software from unauthorized or illegitimate access. It is imperative to establish controls that protect \ networks against information security threats. The primary use of this document is to provide guidance for implementing Network Security controls. ## 2 Scope This document is applicable to all processes and operations in \ within the scope of the ISMS. ## 3 Network Security Management ### 3.1 Network Control * The Engineering Team should have designated employee(s) for managing the \ networks which include cloud environments, VPCs, and cloud services like Office 365 and Google Workspace. * Where feasible, WAF should be configured to automatically provide protocol anomalies reports, traffic analysis, system malfunction signals, etc. * Any changes to the network configurations should follow an appropriate change management process. * Where feasible, logs of these tools/devices should be regularly monitored by the administrators or by using any third-party IDS/IPS tools. * Any anomaly detected is raised as an information security incident through proactive monitoring, wherever applicable and implemented (examples include AWS Guard Duty or Microsoft Defender etc.). * The Engineering Head should ensure that data passing through the network is encrypted using appropriate encryption techniques wherever feasible. ### 3.2 Security of Network Services * The Engineering department should identify the security requirements for the network. These include requirements such as, but not limited to: * Encryption; * Intrusion detection and prevention system; and * Network monitoring. * The Engineering team should ensure that all the identified network security requirements are implemented for the cloud infrastructure owned by \. * If the network services are procured from a third-party service provider, these security requirements should be embedded in the network services agreement, signed with the network service provider. * The Information Security officer along with the Engineering team is responsible for ensuringto ensure a third-party independent network assessment is carried out annually to provide assurance to the management, stakeholders, and other parties involved, and to meet any regulatory requirements. This assessment can be a part of a VAPT exercise as well. * Once the assessment has concluded, results should be documented and officially communicated to the Engineering team to remediate any security issues. * After waiting for allowable time to recover and correct any security issues, the Engineering team should arrange to conduct another test to verify that communicated security issues were addressed and corrected. ### 3.3 Network Access Control #### 3.3.1 Use of Network Services * The Engineering Team should restrict access to any production networks. * The list of users having access to the production network must be maintained, preferably. Whereverr, auto-generation of this list is not possible, it is recommended to manually maintain this. * The Information Security Officer along with Engineering Head should review the access to the production network on a quarterly basis. #### 3.3.2 Remote Diagnostic & Configuration Port Protection All remote access to infrastructure should be configured in a manner such that diagnostic and configuration services are accessible through a dedicated in-band management network interface, over an encrypted application layer protocol such as SSL or SSH only. #### 3.3.3 Segregation of Networks * Networks should be segregated into Virtual Private Cloud (VPC) subnets provided within cloud service platforms. * The data flow between separate network domains should be controlled via secure gateways. * Through a public subnet, the gateway allows respective employees to access either the production or development environment based on their respective roles. * The Engineering Team is responsible for granting access to the production and development environment based on provided user roles and responsibilities. #### 3.3.4 Remote Devices * All devices (Laptops) that access production infrastructure must run current versions of anti-virus software with regularly updated virus definitions. * Users at public hotspots must be aware that, if such a remote device is not running a firewall, a malicious user can gain access to the remote device and install software or remove files from the remote device's hard drive. #### 3.3.5 Firewall Hardening Configuration * Configuration files must be secured and synchronized. * Firewall must be located at each internet connection and between any DMZ and the internal network zone * A list of firewall rules, including business justification for use of all services, protocols and ports allowed must be maintained. * Perimeter firewalls must be installed between all wireless networks and the cardholder data environment (CDE). * Personal firewalls must be installed on any mobile or employee-owned devices that connect to the internet when outside the network and which are used to access the network. * A DMZ must be implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols and ports. * Anti-spoofing measures must be implemented to detect and block forged source IP addresses from entering the network. * System components that store cardholder data must be in an internal network zone, segregated from the DMZ and other untrusted networks. * Private IP addresses and routing information must not be disclosed to unauthorized parties. ## 4 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 5 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 6 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 7 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # Physical & Environmental Security Procedure ## 1 Objective An Information Security Management System (ISMS) has been implemented at \ to protect the organization's sensitive information from unauthorized access, loss, or inaccuracy. Through this document, \ has recognized the need and established guidelines to incorporate physical and environmental security to prevent unauthorized access to physical spaces, avoid damage to assets and prevent interference with the company’s information and information processing facilities. ## 2 Scope The scope of the Physical and Environmental Security procedure is limited to the production environment facilities, their supporting functions, and physical assets. ## 3 Process Responsibilities #### 3.1. Information Security Officer * Reviewing the device security status checks. #### 3.2. Engineering Department and HR * Allocation and deallocation of systems/devices. * Training of users regarding the use of physical assets like Laptops. * Ensuring that the return of information assets and removal of access to systems is done appropriately. ## 4 Physical Security Requirements * \ is a “software as a service” (SaaS) company; a third-party infrastructure provider is hosting the production infrastructure of \. * It is the responsibility of the Information Security Officer, with help from the legal and engineering team, to review the agreements annually and collects vendor’s certificates or security reports (ISO certificate and SOC 2 report) to ensure the credibility of the Infrastructure provider to protect the confidentiality, integrity, and availability of \’s data. * The physical office premises are outside the scope of the ISMS since no production servers or customer data are hosted at our office premises. ## 5 Requirement for Physical Assets * It is the responsibility of each user to protect assets with due importance given to their security. * It is the responsibility of HR to ensure staff with access to assets i.e., laptops shall be made aware of the information security requirements and procedures for protecting unattended equipment, as well as their responsibilities for implementing such protection through periodic ISMS training and awareness programs and as per the asset management policy and HR security policy. * All employees shall be made aware not to leave equipment unattended. Personnel shall be aware to terminate active sessions when finished unless they can be secured by an appropriate locking mechanism. Examples include using password-protected screen savers, log-off from applications when no longer needed, securing laptops or mobile devices from unauthorized use by a password, etc. Personnel shall be made aware of these practices through Information Security Policies and Procedures. ## 6 Clear Desk & Clear Screen Policy Clear Desk Policy applies to paper (hardcopy) and laptops to ensure unauthorized personnel do not have access to \ information. While it is strongly recommended not to use paper assets – in cases where it is required, the following will be applicable: #### 6.1. Clear Desk Policy * Client Confidential / \ Confidential paper assets (project-specific or product development papers) shall not be left unattended to avoid access by unauthorized personnel. * Passwords must always be memorized and must never be written down on paper. * All workspaces must always be left clear before leaving for longer periods of time. * In case of an incident associated with information loss, the matter must be immediately escalated to the Information Security Officer and should follow the Incident Management Procedure. #### 6.2. Clear Screen Policy * Users shall lock their computers when leaving their desks and log off when leaving for an extended period of time. This ensures that the contents of the computer screen are protected from prying eyes, and the computer is protected from unauthorized access. * Use of Laptop / Desktop Privacy Screens shall be considered in case required. * Users shall not keep files/shortcuts on the desktop screen; and * Users shall delete all the files from the recycle bin on a regular basis. ## 7 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 8 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 9 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 10 Schedule This document is to be reviewed annually and whenever significant changes occur in the organization. # Software Development Lifecycle Procedure ## 1 Objective This procedure discusses the objectives, the roles, the process flow, and the artifacts required in a typical software development life cycle. It provides an overview of how the process is adopted throughout various stages of a product and provides guidelines for secure development activities within \. ## 2 Scope This document focuses on the development process for the \ products. This document is to be followed by all \ staff members, sub-contractors, and partners involved in software product development. ## 3 Engineering Team Responsibilities * The Engineering Team shall be responsible for: * Following the guidelines in this document. * Tracking bugs/weaknesses/tools (as applicable). * Assisting third-party vendors in conducting Vulnerability Assessments/Penetration Testing. * The Engineering Head shall be responsible for: * Analyzing new technology for security risks and known attack patterns. * Ensuring all members of the Engineering Team read and understand the process flow and follow the guidelines. ## 4 Process Description ### 4.1. Security Requirements for Information Systems #### 4.1.1. Information Security Requirements Analysis & Specification The main objective of defining a standard process for product development is to ensure cost-effective and timely development, delivery, and deployment of a high-quality, differentiated product that brings tangible and sustained value for \ customers. The following objectives are measured to ensure the effectiveness of the process: * High Quality: * Software produced with less defect count in all development, testing, and delivery cycles. * Metrics: Measure and utilize information on defects/modulesmodule, defects by severity, defects by priority, and defects by different phases of development. * On-time delivery: * Ability to meet the specified delivery dates in every release. * Metrics: Measure the percentage of progress against planned task hours spent in every iterative phase of a product release. ### 4.2. Software Development Life Cycle The Software development life cycle shall include all of the listed stages - Requirement Gathering, Design, Development, Testing, Implementation, Operations, and Maintenance. #### 4.2.1. Requirement Gathering Stage * For each new feature being planned to any software or for changes to existing features, the high-level requirements should be documented by the Product team in consultation with business users. The output of the requirement gathering will form inputs for the Design team. * Where required, it is the responsibility of the Product team to ensure the high-level requirements are detailed into low-level/functional requirements to better facilitate the subsequent tasks of design and development. #### 4.2.2. Design Stage * The Design team is responsible to detail the UI and UX flows for the requirements shared by the Product team. * These details are important inputs to the Engineering team to plan out their development activities. #### 4.2.3. Development Stage * The inputs from the Product team and Design team for the basis for planning of the development stage. * Team leads in the engineering team are responsible for breakingto break down the requirements into tasks and ensuringensure all engineers are aware of the tasks assigned to them. * The engineers are responsible for followingto follow securing coding practices for development. They should also ensure to use the latest code libraries and fix any code-level vulnerabilities. * All development activities should be facilitated by appropriate version control systems to ensure the latest version of code is used for development. * It is the responsibility of the Engineering Head and Infosec officer to ensure the development environment is segregated from the staging and production environment #### 4.2.4. Testing Stage * All features shall be tested after the development is done. * The testing should be performed by any user apart from the developer to ensure segregation of duties. * It is recommended to have the testing to ensure the software is working as intended. * The Engineering Head and Information Security Officer must ensure that testing happens in a staging environment which is different from the development environment and production environment. * Only after adequate testing is completed, the deployment process should commence. #### 4.2.5. Deployment Stage * Any deployment should follow the change management process. It is essential that all deployments are tracked via a version control system or ticketing tool. * All deployments/changes must be approved before merging with production code by an independent engineer who is different from the author to ensure segregation of duties. #### 4.2.6. Maintenance Stage * The engineering team must facilitate the reporting of any errors or bugs identified by the end users. * All such errors/bugs must be tracked. * Any changes related to bug fixes must follow the change management process. ### 4.3. Security in Development & Support Processes #### 4.3.1. Implementing Change Management & Vulnerability Management Procedure * Change management procedure shall be followed for changes to existing systems or the introduction of new systems. Any change made to the system is tested before implementing it. A list of changes made is recorded. Records of testing, updates, and results are documented. * New releases/patches pertaining to the production server shall be tested before being implemented in the production environment to ensure that there is no adverse impact on operation, application controls, or security. In case of any exceptions due to technical limitations, approval shall be taken from the Engineering Head or respective team leads. * Where feasible, automated scanners are used to identify code-level or network-level vulnerabilities, and fixing such vulnerabilities must follow the vulnerability management procedure. * Pull requests/ change requests need to be reviewed by a peer or managers prior to merging the pull requests. * The application functionalities shall be reviewed to ensure that they have not been compromised by the platform changes (as applicable). * Previous version(s) of the software shall be retained as a contingency measure in case a rollback is required. #### 4.3.2. Restrictions on Changes to Software Packages Changes or modifications for vendor-supplied software packages shall be adequately controlled and limited to personnel involved in the implementation of the change/modification based on peer approvals. ### 4.4. Test Data It is the responsibility of product, design, and engineering teams to avoid using any PII data to perform testing. Testing must always be performed using dummy data. ## 5 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 6 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 7 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 8 Schedule This document shall be reviewed annually and whenever significant changes occur in the organization. # Operations Security Procedure ## 1 Objective The objective of this procedure is to provide guidelines to ensure the operational security of \’s services through procedures for backup, change management, logging, and vulnerability management. ## 2 Scope This procedure covers all systems within our production environment. The production environment includes all cloud assets used in hosting and its subdomains. ## 3 Operational Security Procedure ### 3.1. Change Management Procedure #### 3.1.1. Use of Version Control Systems * All software developed in the service of \ or any subdomain of \’s products should be version controlled i.e. the latest version of our software as well as any previous version of our software are readily available. * \ uses a decentralized version control system like git for code changes. This allows engineers to work on bug fixes, new feature development, and other independent projects simultaneously. Before synchronizing with the central repository, it is recommended that engineers work on local branches created from an appropriate version of the central repository. All changes must be tested locally before the changes are deployed to users. #### 3.1.2. Initiating Planned Changes * While developing new features in \’s products, it is recommended to start a new feature branch in git. All requirements and specifications of a feature may not be known at the beginning of the development of the feature. One can create new branches of the feature branch to develop sub-features as necessary. * Most feature branches exist on the local systems of developers working on the feature. They need not be synced with the central, company-wide, repository. However, when a feature is considered ready to be used by customers, a pull request is created. Any developer or software engineer can initiate a pull request. * Alternatively, for other changes like network changes, it is recommended to be tracked in a ticketing platform where change its owner, approver, its impact and details steps for rollback are well documented. #### 3.1.3. Approving Planned Changes * A pull request outlines the differences in code that this feature proposes. A pull request has to be reviewed by other peer developers or managers. All pull requests should be reviewed and approved by someone who is not the author of the changes. It is recommended (but not necessary) that a pull request be reviewed by someone who has expertise in the area where the changes are proposed. * Some automated triggers, like tests, can be integrated with pull requests. That is, a pull request might automatically prompt an automated set of tests to run on the changed code, indicating whether it passes some basic safety checks. Other such checks might include code quality, code linting, or code style checks. The results of such checks are recommended to be logged by the change management system. * A similar approach is recommended in case of using a ticketing system, it should be ensured that every ticket has an owner who raises an approval request to the relevant head * Before approving and merging a pull request or ticket, the reviewer checks that all prerequisites are met. Typical checks that the reviewer is encouraged to perform are listed below. Not all items in the list are necessary (depending on the type of change), nor is the list exhaustive. Please use your judgment to determine what is necessary, depending on the change at hand. Below are some questions to ask: * Does the proposed change solve the problem it set out to solve? Are all requirements for solving the problem met? If not, were reasonable trade-offs made? * Are there any unintended consequences of this change to other parts of the system? * Does the change adversely affect any related or unrelated user experience? * Are there any algorithmic or logical errors in the proposed change? * Does the proposed change require changes in the environment itself (like adding production environment variables etc)? * Could the change create performance issues for itself (or other parts of the system)? * Could the proposed change be achieved in a more extensible, robust, or less disruptive way? #### 3.1.4. Unplanned Changes * Sometimes, it becomes necessary to apply unplanned changes, like hotfixes, to the production system in order to maintain \’s operational effectiveness. This is usually done to address a situation where the production system is in an undesired state - either from a customer-experience standpoint (like critical bugs, system-down, etc.) or from a security standpoint. * Depending on the urgency of the fix required, unplanned changes may skip the requirements of a peer review/approval. Such requests are peer-reviewed post facto. * In such cases, we can create changes in a new branch. For all such cases, the commit and/or pull request messages should detail the nature of the issue being fixed as a result of this change. Unplanned changes follow the same process as planned changes (at least one review or approval from someone who is not the author of the change). * Since we use a version control system, emergency changes can be rolled back if it has unintended or undesirable consequences. ### 3.2. Backup Procedure * \ shall have a daily full backup configured for all customer data on the Infrastructure operated on \. * The backup retention period shall be configured to a minimum of 7 days. * Restoration shall be performed on the backup to ensure that data is readable/accessible. This exercise shall be performed at least once every year. * The restoration tests shall be documented. The backup snapshot that was restored shall be documented along with any sanity checks performed to ensure that the restoration was successful. * Restoration tests shall be performed by the administrators of \’s production infrastructure along with the Information Security Officer. * In an unlikely event of a natural or human-induced disaster, a disaster recovery plan needs to be in place for the systems to recover from the failure and be up and running. This can be achieved in the form of tabletop exercises which must be carried out by the Engineering Head and the Information Security Officer. ### 3.3. Vulnerability Management Procedure * \ performs various internal vulnerability scans and package monitoring on a constant basis. * The Information Security Officer must ensure that \ also performs external vulnerability scans/penetration tests periodically. * All vulnerabilities detected by vulnerability scanners are tracked together along with their severity. * It is the responsibility of the Infra operations person to ensure that vulnerabilities are remediated by the engineering team within defined SLAs (Process Config page). * It is important to track the SLAs for the remediation of vulnerabilities. In case SLA is breached, it is the responsibility of the Information Security Officer along with engineering leads to ensure appropriate actions are taken. E.g. If a vulnerability needs more time to remediate, ensure that the justification for the same is documented. * Vulnerabilities that are identified through external assessments may also be tracked along with other vulnerabilities for their closure if required. * The engineering team addresses the reported vulnerabilities and tracks them to resolution. Resolution statuses can include (but are not limited to) the following: * Fixed: This means that the reported vulnerability has been fixed via a patch or system changes. * Inaccurate/Incorrect/False-positive: This means that the reported vulnerability has been thoroughly investigated, but found to be invalid. * Vulnerable but section unused: This means that the reported vulnerability affects parts of the codebase/system that are not in use, and consequently the vulnerability is no longer a threat. * Acceptable risk: This means that the reported vulnerability has been analyzed and deemed to not pose any debilitating risk to the system. This is a rare-case scenario, and should only occur when there are extenuating circumstances or extremely high remediation costs. ## 4 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 5 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 6 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 7 Schedule This document should be reviewed annually and whenever significant changes occur in the organization. # Vendor Management Procedure ## 1 Objective The objective of this document is to outline the responsibilities and process to be followed while managing relationships with third parties or vendors critical to \’s services. ## 2 Scope This document applies to all staff in \ using various vendors whose services are critical to the operational integrity and availability of the services that \ provides to its customers or with whom critical data is shared. ## 3 Vendor Management Procedure ### 3.1 Responsibilities * It is the responsibility of the Information Security Officer, along with all the Business heads, to ensure the following: * Identifying all \ vendors/suppliers. * Vetting the security controls of third parties before establishing a third-party contract relationship. * Ensuring an approved and up-to-date \ vendor/supplier agreement is in place and has been signed by every third party. * Maintaining a current and accurate listing of all \ vendors/suppliers. * Monitoring third parties for adherence to provisions within vendor/supplier agreements (where applicable), service level agreements (SLAs), and contractual security requirements, as applicable. * Performing periodic or continuous reviews of security measures implemented by third-party service providers. * Business heads must always notify the Information Security Officer whenever they are contracting a new vendor or in case of any changes to services provided by existing vendors. ### 3.2 Managing Contracts and Service Level Agreements * Once a vendor has been selected, it is the responsibility of the Business Heads and Information Security officer to ensure that an official contract has been signed between \ and the vendor. * In the case of using SaaS vendors, subscription-based products may be chosen to carry out business functions, and in such cases, signing contracts is not possible. For all such cases, it is the responsibility of the Information Security Officer to ensure the terms of service published by the vendor are appropriately reviewed. * The Information Security Officer must ensure that Non-Disclosure Agreements or Confidentiality agreements are in place with vendors who have access to sensitive data. In case this is not possible, the Information Security Officer must review the privacy policy published by such vendors. ### 3.3 Vendor Risk Management * The list of vendors must be identified and maintained by the Information Security Officer on a periodic basis. This list must be reviewed at least once a year by the Information Security Officer. * Each vendor is evaluated based on the following principles: * Impact on \’s operations due to unavailability/ breach of vendor services. * Vendor’s access to \’s sensitive data/ information assets. * Further, Vendors must be assessed for their suitability based on the following considerations: * Do we have a way to contact the vendor when we face any service interruptions or degradation? * Does the vendor have any information security certifications like SOC2, ISO27001, etc? * Is there sufficient information from the vendor to indicate the security practices they follow? * In the absence of the above, does the vendor need to be sent a vendor assessment questionnaire? * What are \’s options if the vendor experiences downtime? What happens if the vendor ceases operations suddenly? Are there other potential vendors that \ could work with in such cases? * Based on the evaluation, the criticality of the vendor services is given below: * High * Critical services are disrupted * The vendor has access to most or all critical data * Medium * Critical services are functional * The vendor has restricted access to critical data * Low * Minimal impact on critical services * Minimal access is provided to the vendor * Depending upon the business needs and the severity of the risk of data involved, the vendor’s certificates or security reports must be collected from the vendor. The Information Security Officer should ensure the validity of these reports. * For all vendors that carry the highest risk, appropriate due diligence in the form of reviewing their Information security certifications or evaluations through questionnaires is mandatory. ### 3.4 Vendor Monitoring & Reviews * The Information Security Officer must review the list of vendors and their criticality at least annually. * It is the responsibility of the business heads to ensure that they monitor the service being delivered by the vendors. In case of any deficiencies noted, they must inform the Information Security Officer immediately to ensure corrective measures are taken. ## 4 Document Security Classification Company Internal (please refer to the Data Classification policy for details). ## 5 Non-Compliance Compliance with this policy shall be verified through various methods, including but not limited to automated reporting, audits, and feedback to the policy owner. Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment or contractual agreement. The disciplinary action shall depend on the extent, intent, and repercussions of the specific violation. ## 6 Responsibilities The Information Security Officer is responsible for approving and reviewing policy and related procedures. Supporting functions, departments, and staff members shall be responsible for implementing the relevant sections of the policy in their area of operation. ## 7 Schedule This document should be reviewed annually and whenever significant changes occur in the organization. # Frequently Asked Questions (FAQs) Frequently asked questions about getting started with Sprinto, including setup time, framework changes, staff onboarding, integrations, and policy management. This section answers common questions about setting up and using Sprinto for the first time. If you have a question not listed here, contact our [Support Team](mailto:support@sprinto.com). *** **1. How long does the initial Sprinto setup take?** The setup time depends on the size of your organisation, the number of integrations, and the complexity of your compliance requirements. Most customers complete the core configuration within a few hours, with additional time for policy approvals, training assignments, and vendor assessments. **2. Can I change my compliance frameworks after setup?** Yes. You can enable or disable compliance frameworks at any time from the **Frameworks** page in the Sprinto dashboard. Note that billing is based on enabled frameworks. **3. Do I need to add all staff during the initial setup?** No. You can add staff at any time using integrations, bulk upload, or manual entry. However, adding all relevant team members early helps ensure a smooth onboarding process and accurate compliance tracking. **4. Can I use my own policies instead of Sprinto templates?** Yes. You can upload your existing policy documents, use Sprinto templates, or create new policies using Sprinto’s built-in editor. **5. What if my organisation uses an external training provider?** You can integrate your external provider with Sprinto. Alternatively, you can use Sprinto’s built-in training capabilities to create and assign training campaigns. **6. Do I need a Mobile Device Management (MDM) tool?** Not necessarily. You can use **Dr. Sprinto** to monitor device health without an external MDM. If your organisation already uses an MDM tool, you can integrate it with Sprinto. **7. How do I track onboarding progress for new staff?** Sprinto provides an onboarding workflow that allows you to monitor completion of assigned policies, trainings, and device compliance. You can also send reminders directly from the dashboard. **8. Can I integrate Sprinto with my IAM or ticketing systems later?** Yes. Integrations can be added at any time, whether for IAM tools, infrastructure monitoring, code repositories, or ticketing systems. **9. Is vendor due diligence mandatory?** Vendor due diligence is only required for vendors classified as high risk based on your configured risk assessment criteria. **10. Where can I get help if I’m stuck during setup?** You can: * Contact our [Support Team](mailto:support@sprinto.com) * Access our [documentation](https://sprinto.freshdesk.com/) for step-by-step guides # May 2026 May 2026 Sprinto updates introduce AI-powered compliance workflows, DPIA management, and enhanced risk management capabilities. May focused on advancing Sprinto's **AI-powered compliance capabilities**, expanding privacy management workflows, and making day-to-day governance more efficient. From intelligent framework mapping and autonomous remediation to structured privacy assessments and flexible data collection, these updates help teams reduce manual effort, improve operational consistency, and scale compliance programs more effectively. *** ## Data Protection Impact Assessments (DPIA) Sprinto now supports end-to-end Data Protection Impact Assessments (DPIA), enabling organisations to run structured privacy assessments through configurable workflows, automated task assignment, and AI-generated reporting. ### What's new * Create DPIAs with departments, owners, and approvers * Configure custom workflows for privacy assessments * Automatically assign tasks and notifications * Map risks directly to DPIAs * Generate AI-powered reports summarising outcomes, responses, and risk mappings ### Why it matters * Creates a repeatable and auditable privacy assessment process * Reduces manual coordination across stakeholders * Maintains traceability between privacy assessments and organisational risks * Produces audit-ready documentation automatically ### Availability This is an on-demand feature. Raise a request to get this feature enabled for your organisation.
*** ## Sprinto AI: Expanded Control Mapping Coverage Sprinto AI can now map framework requirements using the entire control library, including disabled controls and control templates, instead of only controls currently enabled within an organisation. ### What's new * AI recommendations now use the full SDC and SCF control libraries * Suggest controls that do not yet exist in an organisation * Automatically import recommended controls during mapping * Configure control packs and mapping sources ### Why it matters * Speeds up framework onboarding * Improves control coverage and gap identification * Reduces manual control mapping effort * Increases accuracy of AI recommendations ### Availability Globally available.
*** ## Fix-it Agent Across Multiple Monitors Fix-it Agent can now remediate multiple failing monitors within a single execution flow. ### What's new * Generate a remediation plan across multiple monitors * Review the execution plan before running fixes * Automatically execute remediation steps ### Why it matters * Resolve multiple compliance gaps simultaneously * Reduce time spent fixing individual monitors * Return to a compliant state faster ### Availability Globally available.
*** ## Auto Generate Workflow Checks for Systems Sprinto can now automatically generate workflow checks for systems without native integrations. ### What's new * Generate checks based on the type of system * Create controls for unsupported applications * Extend compliance coverage without native integrations ### Why it matters * Eliminates dependency on internal experts * Reduces onboarding effort for unsupported systems * Expands compliance coverage quickly ### Availability This is an on-demand feature. Raise a request to get this feature enabled for your organisation.
*** ## Attachment Support in Custom Fields Custom fields now support an Attachment field type, allowing users to upload and manage files directly within workflows. ### What's new * Upload supporting documents, screenshots, and reports * Support for PDFs, images, spreadsheets, ZIP files, JSON files, and more * Preview, download, and remove files directly from the field ### Why it matters * Simplifies evidence collection * Centralises document management * Improves flexibility across workflows ### Availability Globally available.
*** ## Configurable Field Ordering for Risk Profiles Teams can now customise the display order of fields within each Risk Register. ### What's new * Reorder system and custom fields using drag-and-drop * Configure layouts independently for each register * Prioritise the most relevant information for each workflow ### Why it matters * Aligns risk profiles to team-specific workflows * Speeds up reviews and data entry * Improves usability for organisations managing multiple registers ### Availability Globally available.
*** ## Wrapping Up These updates continue Sprinto's investment in **autonomous compliance**, **privacy management**, and **workflow flexibility**. By combining AI-driven capabilities with configurable governance workflows, teams can reduce manual effort, improve audit readiness, and scale compliance operations with greater confidence. # April 2026 April 2026 Sprinto updates introduce AI-powered integrations, vendor and policy registers, smarter monitoring workflows, and enhanced automation across compliance operations. April focused on expanding automation, improving governance workflows, and making compliance operations more scalable across integrations, monitoring, risks, and vendor management. This month’s updates introduced deeper AI-driven automation, stronger risk context, more flexible approval workflows, and operational improvements that reduce manual effort across day-to-day compliance activities. *** ## Monitor Details Page (MDP) UX Refresh The Monitoring Details Page has been redesigned with a more action-oriented experience to help teams resolve issues faster. ### What’s new * New fix-focused default view * Unified “View & Fix” flow across all monitor interactions * Reduced visual clutter to focus on failures and resolution * Improved guidance for next steps and remediation actions ### Why it matters * Faster issue resolution * Lower navigation overhead * Clearer workflows for monitor management and remediation ### Release plan Phased rollout
*** ## Slack Notifications to Common Channels Sprinto task notifications can now be sent to shared Slack channels instead of only individual admins. ### What’s new * Send notifications to multiple Slack channels * Share task updates across broader teams * Configure channel notifications directly from Notification Settings ### Why it matters * Improves team visibility into compliance tasks * Reduces dependency on individual notifications * Speeds up collaboration and response times ### Release plan Globally released.
*** ## AWS Inspector Asset Management Teams can now choose which AWS Inspector resources should be monitored per AWS account. ### What’s new * Granular asset selection for Inspector monitoring * Per-account configuration of monitored resources * Ability to update monitored assets anytime ### Why it matters * Reduces noise from irrelevant resources * Improves vulnerability tracking precision * Gives teams more control over monitored infrastructure ### Release plan Globally released.
*** ## Vendor Registers Vendor Registers introduce a structured way to organise vendors and map them to compliance zones. ### What’s new * Create multiple vendor registers * Map vendors to one or more zones * Run vendor risk assessments directly within registers * Archive and re-enable registers as needed ### Why it matters * Organises vendors by business context or compliance scope * Enables targeted vendor risk assessments * Improves visibility into vendor governance across zones ### Release plan Global release planned in \~3 weeks.
*** ## Policy Updates Sprinto has introduced new AI-powered improvements to make policies more contextual, easier to understand, and more aligned to each organisation’s environment. ### What’s new * **Contextualisation:** Policies are now tailored to an organisation’s industry, business model, tooling, and implemented controls instead of remaining generic templates. * **Know what’s in your policy:** Every out-of-the-box policy now includes a plain-language summary that explains key clauses, obligations, and commitments. ### Why it matters * Reduces policy customisation effort significantly * Makes policies easier for teams to understand and adopt * Improves policy relevance for auditors and stakeholders ### Availability * Contextualisation: Under feature flag (SprintoX only) * Policy summaries: Rolled out
*** ## Extension Improvements Sprinto Assist now supports more advanced remediation and evidence capture workflows. ### What’s new * Improved extension UX with better loaders, completion cards, and remediation guidance * **Auto-screenshot capture post-fix (beta):** Automatically captures evidence after remediation * **Multi-monitor remediation flows (coming soon):** Fix multiple failing monitors in parallel using a generated execution plan ### Why it matters * Reduces remediation effort and operational overhead * Improves evidence capture consistency * Enables scalable remediation workflows for larger environments ### Availability * Auto-screenshot capture: Under feature flag (Autoscout) * Multi-monitor workflows: Coming soon
*** ## Wrapping Up These updates continue Sprinto’s focus on making compliance more automated, configurable, and operationally efficient. From AI-generated integrations and flexible audit scoping to improved vendor workflows and smarter monitoring experiences, April’s releases help teams reduce manual overhead while gaining more control and visibility across compliance operations. # March 2026 March 2026 Sprinto updates introduce AI-powered trust centre interactions, audit findings, bulk uploads, and enhanced risk and access review workflows. March focused on **improving operational efficiency, enhancing risk workflows, and introducing AI-driven experiences** across compliance and trust workflows. From bulk operations and audit enhancements to AI-powered trust centre interactions, these updates help teams **move faster, reduce manual effort, and improve visibility across compliance operations**. *** ### Custom Chart Colours in Risk Registers #### What’s new You can now customise chart colours in the Risks module using a built-in colour picker. This allows you to visually tailor dashboards using hex codes or a colour selector. #### Why it matters * Align dashboards with internal branding * Improve clarity in risk visualisation * Differentiate risk categories more effectively #### Availability Plan 3 & 4 (enabled for select customers)
*** ### Audit Findings #### What’s new Audit Findings introduces a structured way to **create, track, and manage findings directly within audits**. Admins can create findings, assign tasks, and map risks to each finding. #### Why it matters * Centralises audit findings within audits * Enables risk mapping for better traceability * Improves audit visibility and control #### Availability All plans (behind feature flag)
*** ### Risk Bulk Upload #### What’s new You can now upload multiple risks into a register using a structured template with automatic field mapping and validation. #### Why it matters * Faster onboarding of risks * Reduced manual effort * Ensures consistent data entry #### Availability Behind feature flag (limited rollout)
*** ### Vendor Bulk Upload #### What’s new Bulk upload vendors using CSV templates with support for system and custom fields, automatic mapping, and validation. #### Why it matters * Speeds up vendor onboarding * Reduces manual entry errors * Scales vendor management workflows #### Availability Behind feature flag
*** ### Policy Summariser (Employee Portal) #### What’s new Employees can now view a **summary of changes between policy versions**, including added, removed, and modified sections. #### Why it matters * Faster policy review and acknowledgment * Better visibility into changes * Improves employee compliance #### Availability Behind feature flags (enabled for select customers)
*** ### Ask AI on Trust Center #### What’s new Visitors can now ask compliance questions directly within the Trust Center and receive **instant AI-powered responses** based on accessible documents. #### Why it matters * Eliminates back-and-forth during security reviews * Provides instant, contextual answers * Improves Trust Center engagement #### Availability Add-on
*** ### Access Review Delegation Enhancements #### What’s new Access reviews now support **flexible reviewer assignment**, lifecycle consistency, and automated task creation. Key improvements include: * Assign reviewers (Manager, Admin, or Staff) * Bulk update reviewers from User table * Persistent reviewer assignments across lifecycle * Automated task creation and reminders #### Why it matters * Improves accountability and ownership * Enables flexible delegation across teams * Enhances visibility into review progress #### Availability Limited rollout (feature flagged)
*** ### Wrapping up These updates collectively strengthen Sprinto’s platform by: * Reducing manual effort through bulk operations * Improving audit and risk visibility * Enhancing user experience across workflows * Introducing AI to simplify compliance interactions Together, they enable teams to **scale compliance operations with better control, clarity, and efficiency**. # February 2026 February 2026 updates introduce enhanced automation, vendor lifecycle management, approval workflows, and usability improvements across Sprinto. February focused on strengthening governance workflows, improving vendor lifecycle management, and enhancing usability across core operational modules. These updates introduce structured intake and approval systems, expand automation capabilities, and streamline everyday workflows — helping teams operate with greater control, visibility, and efficiency. *** ### Create Automations with the Rule Engine (Admin Portal) Automation capabilities have been expanded with the introduction of rule creation directly within the Admin Portal. #### What’s new * View and manage all automations from **Settings → Automations.** * Create and configure rules using a UI-based rule builder. * Select trigger types such as **Create**, **Update**, or both. * Aligns with existing Command Centre capabilities. #### Why it matters * Makes automation more accessible without relying on backend workflows. * Enables faster setup and management of rules. * Reduces manual intervention across compliance workflows.
*** ### Access Review Table Enhancements The Access Review table has been redesigned to improve usability and actionability. #### What’s new * Upgraded to a structured, standardised data table. * Perform bulk actions such as **Mark as Okay**, **Revoke**, and **Downgrade.** * Contextual recommended actions based on detected issues. * Improved organisation for Case Owners and InfoSec teams. #### Why it matters * Reduces repetitive manual actions. * Helps teams take faster, more informed decisions. * Improves efficiency of access review workflows.
*** ### Multi-step Approval Paths for Risks (Upgrade) Existing risk approval workflows have been upgraded to support multi-step approvals. #### What’s new * Multiple sequential approval steps with configurable logic. * Supports **AND / OR** approval conditions within steps. * Automatic progression across approval stages. * Enhanced rejection and resubmission flow. #### Why it matters * Enables more structured and flexible approval workflows. * Improves visibility into approval progress. * Strengthens governance and accountability in risk reviews.
*** ### Vendor Requests Vendor Requests introduce a structured workflow for managing vendor intake from employees. #### What’s new * Centralised view of all vendor requests * Approve or reject requests with decision tracking * Map requests to existing or new vendors * Customise request forms using configurable fields #### Why it matters * Improves visibility into vendor onboarding requests * Reduces shadow IT and unmanaged vendor usage * Enables structured vendor intake and tracking
*** ### Vendor Offboarding Vendor Offboarding provides a standardised way to manage vendor exits using task-based workflows. #### What’s new * Create offboarding checklists with predefined tasks. * Automatically assign tasks when a vendor enters the Offboarding stage. * Track offboarding activities within vendor profiles. #### Why it matters * Ensures consistent vendor exit processes. * Reduces risks from lingering access or dependencies. * Strengthens end-to-end vendor lifecycle management.
*** ### Risk Intake Risk Intake enables employees to report risks directly, with admin-controlled onboarding into the risk register. #### What’s new * Employees can submit risks via the Employee Portal. * Admins review, approve, or reject submissions. * Approved risks are added to selected risk registers. * Configure reviewers, fields, and intake settings. #### Why it matters * Improves visibility of risks across the organisation. * Ensures controlled and structured risk onboarding. * Reduces the likelihood of missed or untracked risks.
*** ### Vendor Approval Paths Approval Paths can now be configured specifically for vendor requests. #### What’s new * Multi-step approval workflows for vendor requests. * Configurable approvers, logic (AND/OR), and timelines. * Automatic routing and step progression. * Track approval status within request details. #### Why it matters * Ensures vendors are reviewed before onboarding. * Improves decision transparency and accountability. * Supports enterprise-grade approval workflows.
*** ### Task Dashboard UI Refresh The Task Dashboard has been refreshed to improve task visibility and usability. #### What’s new * Default **“Assigned to Me”** view for focused task management. * Interactive cards for quick filtering (e.g., Escalated, Pending). * Centralised filters for faster navigation. * Cleaner, more readable data table. #### Why it matters * Helps users prioritise and act on tasks faster. * Reduces time spent navigating task lists. * Improves day-to-day operational efficiency.
# January 2026 January 2026 updates introduce improved integration error handling, weighted risk scoring, automation with rule engine, control testing, and Terraform-based remediation in Sprinto. January focused on strengthening integration reliability, improving risk accuracy, and accelerating remediation workflows across Sprinto. Teams now benefit from a more consistent integration error handling experience, more accurate risk treatment calculations, and expanded automation capabilities. Together, these updates help organisations operate with greater clarity, speed, and control. *** ### Improved Integration Error Handling Integration error handling has been standardised across Sprinto, providing clearer visibility into sync issues and faster resolution paths. #### What’s new * Last sync and error details are now visible across all integration areas, including Staff Devices, Incidents, and Vulnerabilities. * Consistent error handling across overview pages, data tables, and provider pages. * AI-powered troubleshooting steps for resolving user-side errors. * Error-based filtering to surface integrations with active issues. #### Why it matters * Faster identification and resolution of integration issues. * Reduced dependency on support teams. * Clear, consistent visibility into integration health.
*** ### Control Weightage for Risk Treatment Effectiveness Risk treatment effectiveness can now be calculated using weighted scoring based on control importance. #### What’s new * Assign custom percentage weights to controls and tasks linked to a risk. * Weighted scoring replaces simple averaging. * Configure control weightage from the Risk Register settings. #### Key capabilities * Set weights (up to two decimal places) for controls, task groups, and tasks. * Enforced total weight of 100% with system validation. * One-click reset to redistribute weights. #### Why it matters * Reflects real-world control criticality. * Improves accuracy of risk evaluation. * Enables better prioritisation for risk owners and auditors.
*** ### Create Automations with the Rule Engine Teams can now automate workflows using condition-based rules within Sprinto. #### What’s new * Create rules to automate actions based on entity conditions. * Available via Command Centre (UI support coming soon). #### How it works * Define rules using default or custom fields. * Configure actions such as notifications, emails, or AI-driven actions. * Rules trigger automatically when records are created or updated. #### Why it matters * Reduces manual effort and follow-ups. * Ensures consistent and scalable workflows.
*** ### Create Findings and Tasks for Controls Control workflows have been enhanced with better traceability and task management. #### What’s new * Refreshed Controls page with improved usability. * Add findings to controls within zones. * Create tasks from findings or directly from controls. #### Why it matters * Improves traceability between controls, findings, and remediation. * Helps teams track and close compliance gaps faster.
*** ### Set Up Testing for Controls Teams can now define and run structured tests for controls using custom scoring methods. #### What’s new * Create custom scoring methods for control testing. * Apply scoring methods individually or in bulk. * Configure testers, instructions, and testing frequency. * Visualise results as score trends on control pages. #### How it works * Testers initiate tests and enter scoring values. * Final scores are automatically calculated and stored. * Supports zone-specific testing configurations. #### Why it matters * Enables structured and repeatable control evaluation. * Aligns testing with internal methodologies. * Improves visibility into control performance over time.
*** ### Terraform Fix-It Templates for Infrastructure Monitors Infrastructure remediation is now faster with built-in Terraform fix templates. #### What’s new * Step-by-step Terraform (HCL) code available directly in Sprinto. * Copy-paste snippets with clear instructions and explanations. * Supports Terraform-managed infrastructure. #### Why it matters * Eliminates the need for external troubleshooting resources. * Speeds up remediation of compliance gaps. * Enables faster resolution of monitor failures. #### Release details * Coverage currently includes the most common AWS monitors. * Expanding based on customer demand. * Available behind feature flag: `terraform-fix-code` .
# December 2025 Discover Sprinto’s December 2025 product updates featuring AI-powered automation, enhanced risk management, advanced policy approvals, and improved trust and control workflows. December brought major advancements in automation, policy governance, risk management, and trust workflows across Sprinto. This month’s releases enhance accuracy, reduce manual effort, and make compliance operations more intelligent and scalable. *** ## **Fix-It Agent** #### **What’s new** The Fix-It Agent provides automated, step-by-step fixes for common misconfigurations across integrations.\ It detects issues, explains the cause, and guides users through resolving them directly from Sprinto. #### **Why it matters** * Reduces dependency on support for routine integration errors * Ensures faster recovery from configuration issues * Helps teams maintain real-time compliance posture #### **Release** * Behind feature flag * Rolling out to selected customers across regions
*** ## **Sprinto AI Debugger** #### **What’s new** The Sprinto AI Debugger analyzes incoming vendor errors and offers: * Root-cause explanations in simple, readable language * Actionable fixes with validation steps * Integration-specific troubleshooting for AWS, GitHub, Jira, Google Workspace, Rippling, and others\ Accessible from Integrations → Errors tab and via Data Library drawers. #### **Why it matters** * Greatly reduces support escalations * Enables users to self-resolve integration errors * Standardizes error handling and remediation
*** ## **Multiple Risk Registers** #### **What’s new** Organizations can now maintain multiple risk registers within the same zone. Each register includes: * Independent scoring schemes * Custom types, categories, fields, and risk managers * Per-register monitoring and periodic assessments * Full configuration isolation for tailored risk programs #### **Why it matters** * Eliminates the need for multiple zones just to manage separate registers * Supports department-wise, framework-wise, or project-wise risk segmentation * Creates cleaner, more structured risk governance
*** ## **Approval Paths for Policies** #### **What’s new** Policy approvals now support configurable **multi-step approval paths**. Teams can: * Add multiple sequential steps (Step 1 → Step 2 → Step 3) * Configure AND/OR approval logic per step * Auto-progress to the next step upon completion * Use built-in rejection and resubmission flows * Track progress and send reminders from the policy drawer #### **Why it matters** * Enables structured, audit-ready governance for policy updates * Accommodates complex organizational approval chains * Standardizes review cycles across teams
*** ## **Trust Suite Updates** *(AI-Powered Security Questionnaire + Trust Center Analytics)* ### **AI-Powered Security Questionnaire** #### **What’s new** Teams can now generate complete questionnaire responses using Sprinto AI, with: * Automated, context-aware answers * Support for customizable prompts and tone * Fine-tuning via live editing and formatting #### **Why it matters** * Reduces hours of manual questionnaire work * Ensures consistent, high-quality responses * Speeds up security reviews during sales cycles *** ### **Trust Center Analytics** #### **What’s new** A new analytics dashboard provides insights into Trust Center performance, including: * Visitor activity * Document engagement * Download patterns * Update subscription metrics #### **Why it matters** * Helps organizations understand stakeholder interest * Supports better preparation for audits, renewals, and sales cycles * Enhances visibility into documentation effectiveness *** ## **Control Testing** #### **What’s new** Users can now test controls using **custom scoring methods**, with: * Control-specific scoring assignment * Automatic notifications when tests are due * Score trends displayed directly on the control page #### **Why it matters** * Enables evaluations that match internal criteria * Supports more accurate control health measurement * Helps teams validate control performance continuously
*** ## **Control Findings** #### **What’s new** Control pages now support: * Creating findings and tasks for any control * Viewing findings directly under each control * A redesigned UI for clearer readability #### **Why it matters** * Centralizes all evidence, issues, and remediation tasks * Improves audit readiness with structured findings * Enhances usability for control owners and reviewers
# November 2025 Sprinto November 2025 brings AI-powered automation, real-time evidence capture, framework flexibility, and multiple integration and UX upgrades to streamline audits and compliance operations. Sprinto delivered major advancements in automation, evidence handling, policy intelligence and UI consistency this month, helping teams work faster, reduce manual compliance effort, and improve audit clarity. *** ### November Highlights #### Sprinto AI Agents - Automated Issue Resolution & Compliance Ops Sprinto AI Agents help resolve issues, answer questionnaires, and detect compliance gaps, bringing automation to audits and daily workflows. **What’s new** * AI automation across compliance operations * Detects issues, suggests and executes fixes * Used by 60+ orgs with measurable throughput gains * 25+ custom agent workflows already running **Why it matters** * Reduces manual audit work * Speeds up response cycles * Improves audit readiness with ongoing assistive automation *** #### Infinite Frameworks - Map Anything to Anything Teams can now map every Sprinto object to any external standard, creating flexible, future-proof compliance coverage. **What’s new** * Framework-agnostic mappings for all policies, checks and risks * Flexible cross-framework relationships * Support for industry, customer or regulatory frameworks **Why it matters** * Adapts to evolving compliance requirements * Enables custom frameworks driven by market or customer needs * Eliminates multi-standard duplication and rework *** #### Sprinto Extension - Real-Time Evidence Collection Capture screenshots and configuration evidence directly from cloud consoles and web apps without switching tools. **What’s new** * Browser extension for live evidence capture * Validated evidence stored directly in Sprinto * Timestamped, traceable proof for auditors **Why it matters** * Eliminates scattered screenshots * Avoids repeated uploads and manual tagging * Improves transparency and audit traceability *** #### Link Assets Directly to Risks - Live Risk Context Link vendors, systems, policies, findings and more to risks for contextual, dynamically updated risk posture. **What’s new** * Entity-level risk linkage across Sprinto * Automatic traceability when assets evolve * Supports digital systems, findings, vendors and devices **Why it matters** * Moves risk from theoretical to real-world * Helps prioritise actions proactively * Improves accuracy of risk assessments *** #### Policy Drift Detection - Assisted Policy Updates Sprinto detects inconsistencies between policies, workflow checks and frameworks — helping teams maintain compliant documentation. **What’s new** * Drift flags across frameworks, automated checks and workflows * Side-by-side comparison of existing vs recommended content * One-click updates with suggested improvements **Why it matters** * Keeps policies aligned with actual controls * Prevents auditor-discovered mismatches * Simplifies version updates and reviews *** #### Integration Agents - Automated Sync Across Systems The Integration Agent seamlessly connects cloud services, HR systems, and other third-party tools to Sprinto, automatically syncing key security and configuration data. **What’s new** * Automated, event-driven syncing across cloud, HRMS, and SaaS tools * Keeps Sprinto’s evidence, controls and risk posture continuously up to date * Minimises setup complexity with a unified connection layer **Why it matters** * Eliminates stale data and manual export/import cycles * Ensures your compliance posture always reflects real activity * Reduces integration maintenance for admins and engineers *** #### Coming Soon - Fix-It Agent (Preview) Guided remediation flow powered by AI, tied directly to Sprinto records. **Planned capabilities** * Auto-guided remediation steps * Contextual resolution actions logged automatically * User-guided verification and redo path **Why it matters** * Eliminates avoidable back-and-forth * Reduces remediation delays * Improves audit documentation and traceability *** ### Other Updates #### OnGrid Integration - Background Verification Provider OnGrid is now supported as a vendor integration to automate BGV (Background Verification). **What’s new** * API-based onboarding with Client ID, Secret and Community ID * BGV status and results synced into Sprinto * Support for two checks and full evidence handling **Why it matters** * Improves HR audit traceability * Eliminates scattered BGV documentation * Ensures BGV flows align with compliance needs *** #### Bulk AI Actions - Review and Enhance Multiple Records Run any AI Action across many policies, risks or questionnaires at once. **What’s new** * Bulk execution of Sprinto or custom AI Actions * Parallel processing of reviews and enhancements * Download or inspect results record-by-record **Why it matters** * Eliminates repetitive compliance editing * Speeds up audit review cycles * Scales AI improvements across large data sets *** #### Entity Detail Standardisation - Unified Layout Across Sprinto A redesigned detail panel provides predictable navigation across People, Access and Infra. **What’s new** * Unified layout and interaction model * Full-width view with instant metadata visibility * Backend enhancements for clarity and consistency **Why it matters** * Reduces cognitive load * Makes troubleshooting and reviews faster * Improves usability across multiple Sprinto modules *** #### JumpCloud Integration - IAM Evidence Automation JumpCloud is now available under feature flag for IAM-level monitoring. **What’s new** * Automates IAM evidence and device details * Maps device posture signals for compliance checks * Full metadata synced into Sprinto drawers **Why it matters** * Simplifies identity evidence collection * Reduces manual user/account reporting * Enables IAM policy and access audits end-to-end *** #### Jira Enhancements - Assignee & Reporter Metadata + Attachments Incident and change evidence from Jira is now richer and more audit-ready. **What’s new** * Assignee and reporter fields pulled for all Jira records * Attachments automatically synced into Sprinto * Traceability available directly inside drawers **Why it matters** * Improves accountability for remediation actions * Eliminates manual attachment uploads * Strengthens incident audit trail *** #### Trust Center - Major UX Upgrade The Trust Center has been redesigned with a cleaner UI and improved usability. **What’s new** * Bulk access requests — retrieve all documents at once * Persistent overview panel across all pages * Fast document navigation from framework/resource cards * Customisation options: solid colour, image, gradient **Why it matters** * More professional and consistent external presence * Easier navigation for customers and auditors * Faster access to key compliance material # October 2025 Discover Sprinto’s October 2025 Product Updates, featuring AI-led mapping, smarter vendor management, new device checks, and enhanced integration workflows for faster, more connected compliance. October brought powerful new updates across integrations, automation, vendor management, and AI enablement, all designed to make compliance in Sprinto faster, smarter, and more intuitive. From improved mapping transparency to new vendor management flows and device checks, this month’s releases drive clarity, efficiency, and trust across your workflows. *** #### **Policy–Control AI Mapping Enhancements** Sprinto’s **Policy–Control AI Mapping** is now more transparent and accurate.\ Mappings deliver broader coverage across large policies with **no suggestion limits**, and every control now includes a clear rationale — showing the **policy section, requirement reference**, and **linked framework criteria** that informed the mapping. **Why it matters:**\ This transparency helps you validate AI-suggested mappings faster and with more confidence, making your compliance automation both smarter and easier to audit.
*** #### **Frameworks Page UI Update** The **Frameworks Page** has received a visual upgrade with a new **Grid View**.\ Easily switch between grid and list modes to manage frameworks visually, track readiness, and see progress across SOC 2, ISO 27001, HIPAA, and more, all in a single view. **Why it matters:**\ You get a cleaner, modern interface and improved visibility for audit tracking and framework management.
*** #### **Vendor Management Enhancements** **Default Vendor Document Request Templates** You can now create a **default vendor document request template** to streamline due diligence workflows.\ Set up your preferred document and VSQ list once under **Configuration → Vendor Document Request** and reuse it across all vendors. **Highlights:** * Customise email content and notifications. * Select who in your org should be notified. * Choose to display document lists in vendor emails. * Modify and send requests in one click. **Why it matters:**\ This saves hours of manual setup and ensures consistency in every vendor assessment.
*** **Track Vendor Document Requests Easily** You can now view and manage all vendor document requests directly from the new **‘Requests’ tab** in **Vendor Documents**. **What’s New** * View a full list of document requests sent to vendors. * Track requested documents and VSQs per request. * Add more vendor contacts or recall a request. **Why it matters:**\ Gain end-to-end visibility into vendor submissions and follow-ups, ensuring timely responses and better control over due diligence workflows.
*** #### **Trust Centre Subscriptions** Visitors can now **subscribe to Trust Centre updates**.\ External stakeholders can enter their email and automatically receive notifications whenever a new update is published, no login required. **Why it matters:**\ It helps you maintain transparency with customers, auditors, and partners effortlessly. Admins can also view the full subscriber list in the admin panel.
*** #### **Ask AI for Help Documents** The new **Ask AI** assistant is now live inside Sprinto. It lets you search help documentation and get **instant, doc-backed answers** without leaving the app. **Example use cases:** * Learn how to connect integrations. * Troubleshoot failed checks. * Understand workflows in context. **Why it matters:**\ Teams can self-serve faster, onboard independently, and find accurate answers directly within Sprinto.
*** #### **Ask AI in Knowledge Hub** Ask AI now extends to the **Trust Knowledge Hub**, enabling you to ask questions about synced policies, procedures, and controls.\ AI searches your **synced documents and Q\&A** to provide accurate, contextual responses about your compliance posture. **Why it matters:**\ You get faster, context-rich answers for both internal clarifications and external audit queries.
*** #### **Screenlock Check for JAMF Devices** Sprinto now supports **Screenlock checks for JAMF-managed devices** under **Staff Devices**.\ This feature ensures that all staff devices enforce screenlock and access control continuously. **Why it matters:**\ Enhances endpoint visibility and strengthens compliance coverage for access control requirements.
*** #### **Azure DevOps: Migration to New Connection Method** Azure DevOps integrations now use the **Entra ID–based connection method**.\ All users in the US, IN, and EU regions should reconnect their Azure DevOps accounts to maintain automation. **Why it matters:**\ This ensures uninterrupted evidence syncing and keeps integrations aligned with Microsoft’s latest standards.
*** #### **Smart Post-Integration Connection Flow** Integrations are now classified and configured through a **guided connection flow**. **What’s new:** * Clear classification between **single-purpose** and **multi-purpose** integrations. * Guided setup directly on the integration page. * Improved visibility into connection status. **Why it matters:**\ Simplifies setup, reduces confusion, and speeds up integration onboarding.
*** ### **Key Highlights** October brought **AI-powered transparency**, smarter **vendor management**, improved **integration setup**, and expanded **device coverage,** all building toward a more connected compliance experience inside Sprinto. # August - September 2025 Explore Sprinto’s August–September 2025 product updates, featuring AI automation, Microsoft Teams integration, enhanced IDP sync, bulk mapping, exception management, and smarter compliance workflows Welcome to the **August–September 2025 edition** of Sprinto Product Updates!\ We’ve rolled out several powerful enhancements designed to make compliance smarter, faster, and more intuitive, from AI automation to integrations that bring compliance closer to your daily tools. *** ### **AI Playground & Ask AI (Beta)** Bring no-code AI automation directly into Sprinto with the **AI Playground** and the in-app assistant, **Ask AI**. **What’s New** * **Action Builder (no code):** Describe your task, and Sprinto creates reusable AI Actions across policies, risks, vendors, and audits. * **Ask AI in context:** Run actions or ask natural-language questions directly where you work (supported across 15+ entities). * **Starter Library:** Access 15+ ready-to-use AI Actions, like policy refinements or vulnerability fixes. * **Admin Control:** Centrally manage, edit, or disable actions as needed. **Why It Matters**\ This feature brings flexible, no-code AI capabilities into compliance workflows, empowering teams to automate processes without engineering help.
*** ### **Faster Onboarding & AI for Security Questionnaires** We’ve redesigned the onboarding flow to make completing your first questionnaire faster and easier. **What’s New** * **Smarter start:** Upload your own documents or use Sprinto’s pre-built templates. * **AI-powered answers:** Generate context-aware, accurate responses in real time. * **Seamless flow:** Resume where you left off and export completed answers instantly. **Why It Matters**\ Get through onboarding smoothly and reduce setup friction, helping you achieve faster compliance readiness.
*** ### **Enabling Graded Audit Assessments** Sprinto now supports graded audit evaluations for frameworks like **NIST CSF**, **CMMC**, and **COBIT**. **What’s New** * **Configurable scoring:** Define custom maturity levels or rating scales. * **In-platform scoring:** Auditors can score assessments directly within Sprinto, no spreadsheets required. * **Real-time visibility:** Export data instantly as CSVs for deeper analysis. **Why It Matters**\ Move beyond binary outcomes and gain nuanced insights into your compliance posture over time.
*** ### **Creating Entity Groups Locally** You can now create and manage staff groups directly in Sprinto, no external imports required. **What’s New** * **Manual & dynamic groups:** Build groups using staff lists or attributes. * **Auto-updating membership:** Dynamic groups automatically stay current. * **Smarter workflows:** Use groups for scoping, policy assignment, and training. **Why It Matters**\ Simplifies team management, eliminates repetitive setup, and makes large-scale compliance easier to organise.
*** ### **Microsoft Teams Integration** Sprinto task notifications are now available in **Microsoft Teams**, alongside Slack and Email. **What’s New** * Receive staff and admin task notifications directly in Teams. * Stay updated on pending tasks and compliance actions in real time. **Why It Matters**\ Stay on top of compliance tasks without switching tools, all within your daily collaboration workspace. **What’s Next**\ We’re expanding Teams notifications to include **policy acknowledgements** and **employee task alerts** in upcoming releases.
*** ### **People Section Sync & Custom Mapping** We’ve enhanced how Sprinto connects with your **IDP** and **HRMS** systems. **What’s New** * **Continuous sync:** Keep names, emails, and extra fields updated across Google Workspace, O365, Okta, OneLogin, and Zoho. * **Source priority:** Set a primary source of truth and pull deltas from others. * **Custom field mapping:** Map provider fields (for example, Role → Department) to Sprinto. **Why It Matters**\ Reduces manual edits, improves visibility, and ensures data consistency across systems.
*** ### **Bulk Map Criteria to Control** Map up to **200 compliance criteria** in under **2 minutes** with AI-powered bulk mapping. **What’s New**\ Sprinto auto-generates control mappings that you can review and finalise, turning hours of work into minutes. **Why It Matters**\ Saves teams significant time while ensuring audit readiness and mapping accuracy.
*** ### **Exception Management** You can now raise and manage exceptions directly in Sprinto. **What’s New** * Raise requests to deviate from a policy or control. * Admins can link to policies, map risks, and define mitigating controls. * Both sides can track requests via real-time dashboards. **Why It Matters**\ Provides a structured, auditable way to handle exceptions, improving visibility and reducing compliance risks.
*** ## **That’s a wrap for August–September!** We’re continuously improving Sprinto to make compliance smarter, faster, and more collaborative. Stay tuned for more updates next month. # Overview Get a unified, real-time view of compliance posture, pending work, and risks across Sprinto through the central dashboard and streamlined navigation. The **Sprinto Dashboard** is the central hub for monitoring your organisation’s governance, risk, and compliance (GRC) posture. It brings together real-time data on control readiness, pending compliance tasks, and ongoing risk treatment effectiveness. The dashboard is split into three main sections: 1. **Control Health Dashboard** – monitor control readiness and check health across compliance areas. 2. **Task Dashboard** – manage pending compliance tasks with advanced filtering and assignment. 3. **Continuous Risk Monitoring** – evaluate the effectiveness of risk treatments and residual risks. Here's a short video giving a brief overview of the dashboard. {% embed url="" %} *** #### Left Navigation — Quick Access to All Modules Sprinto’s left-hand navigation menu gives you quick access to all key modules: * **Dashboard** – The central view, containing Control Health, Continuous Risk Monitoring, and Tasks. * **Audits** – Manage ongoing and planned audits, view evidence, and track audit tasks. * **Policies** – Create, assign, and manage compliance policies and track policy acknowledgements. * **Risks** – Maintain your risk register, score risks, and track treatments. * **Compliance** – Access frameworks, controls, and compliance resources. * **Data Library** – Manage assets, incidents, and related compliance documentation. * **Monitoring** – Review and configure automated Sprinto checks. * **Trust** – Manage trust centre content, questionnaires, and disclosures. * **Settings** – Configure integrations, zones, roles, security settings, and organisation details. This logical grouping aligns with GRC best practices, reducing cognitive load and helping teams navigate between related areas quickly.
*** #### Key Dashboard Sections **1. Control Health Dashboard** * **Purpose:** Tracks readiness of all mapped controls across compliance areas. * **Metrics:** Control readiness %, passing/failing/critical/due checks, and pending setup count. * **Actions:** Drill down into compliance areas, review mapped checks, and address failing controls. **2. Task Dashboard** * **Purpose:** Centralises all pending compliance tasks. * **Metrics:** Task counts by severity and time-to-fix indicators. * **Actions:** Filter by zone, role, area, and status; assign and escalate tasks; complete certain tasks inline. **3. Continuous Risk Monitoring** * **Purpose:** Monitors and evaluates ongoing risk treatment effectiveness. * **Metrics:** Average inherent risk, residual risk, and treatment effectiveness. * **Actions:** Review treatment readiness at a risk and control level, address low readiness areas. *** #### Why This Matters The Sprinto Dashboard provides: * **Real-time compliance visibility** across all areas. * **Actionable insights** with drill-down navigation to specific product areas. * **Streamlined navigation** to all governance, risk, and compliance modules. * **Zone-specific filtering** for distributed teams or multiple entities. # Support for Secure Controls Framework (SCF) Sprinto now supports both the **Secure Controls Framework (SCF)** and the **Common Control Framework (CCF)**, giving your organisation flexibility in how you structure and manage compliance controls. This enables alignment with your internal GRC strategy while leveraging Sprinto’s automation and mapping capabilities. *** ### **Set the Default Control Pack During Signup** When creating a new organisation via a signup link, you can predefine the default control pack that will be used for future framework activations. To configure the default control pack: 1. Go to the **Signup Link** configuration screen. 2. Locate the **Default Control Pack** setting. 3. Choose one of the following options: * **CCF (Sprinto Default Controls)** * **SCF (Secure Controls Framework)** Once set, all future framework activations for that organisation will default to the selected control pack—if the framework supports it. *** ### **View Enabled and Available Frameworks** The **Frameworks** page has been redesigned for improved visibility and categorisation. To access it: 1. Navigate to **Compliance > Frameworks**. 2. You’ll see two distinct sections: * **Enabled Frameworks** – Frameworks currently active in your account. * **Available Frameworks** – A library of additional frameworks you can activate. Use the tabbed interface or toggles to switch between the two sections. *** ### **Enable Frameworks Using Control Pack Logic** When enabling a new framework, Sprinto applies control mappings based on your organisation’s default control pack. #### Mapping Logic: * If the selected framework is compatible with your **default control pack** (SCF or CCF), that pack is applied automatically. * If the framework **does not support** your default pack, Sprinto falls back to the next best compatible pack (typically CCF). **Example:** * If your organisation has SCF set as the default, and you enable **SOC 2**, Sprinto applies **SCF** controls (as SOC 2 supports both). * If you enable a framework like **Rainbow**, which supports only CCF, Sprinto applies **CCF** controls by default. #### To enable a framework: 1. Go to **Compliance > Frameworks**. 2. Go to the **Available** tab.
3. Select the framework you wish to enable. 4. Click **Enable framework**.
5. Sprinto will apply the appropriate control pack based on your organisation’s settings. *** ### **Request a Custom Control Pack Mapping** If you need to override the default control pack applied to a framework: 1. Raise a request in the **#special-ops** Slack channel (or via your support contact). 2. Specify the framework and the control pack you wish to apply. 3. The Sprinto team will update the mapping using internal tools. {% hint style="warning" %} Manual overrides are processed by Sprinto and may take up to 24 hours to complete. {% endhint %} # Communication of Staff Related Activities Email Template ``` Dear Sprinto Customer, please use the email template and share it with your team to ask them to finish the staff related activities on Sprinto. ``` Hi \, \ is undergoing a SOC2, ISO, GDPR, and HIPAA compliance journey. As a part of compliance, all employees must perform simple tasks listed on the Sprinto dashboard. Please follow these steps & complete them on priority. 1. Go to and log in using your Embie credentials ("Login with Google" prompt) or OTP for those without an Embie email address. 2. Under the [policies section](https://app.sprinto.com/app/intranet/policies), click on the ‘Review & accept all policies’ button. Read all the policies and then check the checkbox of ‘I have read and accept the policies’ and then press accept all policies. 3. Under the[ Security training section](https://app.sprinto.com/app/intranet/securityTraining), go through all the slides to complete security and privacy training. If you are versed in these policies, you can take the test without reviewing the slides. 4. Navigate to the “[Your devices](https://app.sprinto.com/app/intranet/endpointScanLogs)” tab. This is where we ensure that your devices that you develop with, will have basic protections enabled. The following checks need to be done on each development device and a screenshot evidence should be provided to show that the check was done and succeeded. 1. System needs to be updated . On mac: 1. From the Apple menu in the corner of your screen, choose System Preferences. 2. In the System Preferences window, click Software Update. (If your System Preferences doesn't include Software Update, use the App Store to get updates instead.) 3. Click Update Now or Upgrade Now. 4. For more details, please see Apple help page on [how to update/upgrade MacOS](https://support.apple.com/en-in/HT201541). On Windows: 1. Open \[Windows Update] in the Settings. 2. Install any outstanding updates. 3. Restart the system if prompted. . On linux: 1. Open Software Updater. 2. Install any outstanding updates. 3. Restart the system if prompted. 4. If you don't see any available updates, you may need to upgrade to a release of your distribution that is still supported and is receiving security patches from the vendor. 5. Disk encryption should be enabled. On mac: 1. Choose System Preferences from the Apple menu. 2. Click \[Security or Security & Privacy] 3. Click the \[FileVault] tab. 4. Unlock the pane by clicking the lock in the lower-left corner and enter the administrator username and password. 5. Click "Turn On FileVault" to start the process. On Windows: 1. Open \[BitLocker Drive Encryption]\(prefs\://BitLocker). 2. Click "Turn on BitLocker". . On linux: 1. The recommended option for full disk encryption for Linux is [LUKS](https://gitlab.com/cryptsetup/cryptsetup/-/wikis/home). 2. You can find instructions for Ubuntu 19.04 and 20.04 below. 1. [Ubuntu 19.04](https://medium.com/@chrishantha/encrypting-disks-on-ubuntu-19-04-b50bfc65182a) 2. [Ubuntu 21.04 dual boot with Windows 10](https://gist.github.com/luispabon/db2c9e5f6cc73bb37812a19a40e137bc) 3. Screen Lock should be enabled . On mac: 1. Choose System Preferences from the Apple menu. 2. Click \[Security or Security & Privacy]. 3. Select the \[General] tab. 4. Unlock the pane by clicking the lock in the lower-left corner and enter the administrator username and password. 5. Check the "Require password" box and set the pull down menu to to "immediately" after sleep or screen saver begins. 6. Make sure the Screen Saver is enabled as well. On Windows: 1. Open \[Lock screen settings]. 2. Scroll down and click on "Screen saver settings". 3. Select a screen saver of your choice and a wait time of less than 15 minutes. 4. Select the option "On resume, display logon screen". . On linux: Ubuntu 18.04: 1. From the upper-right drop-down menu, click the Settings icon. 2. In the left-hand pane, select Privacy. 3. Click on ScreenLock 4. Ensure that "Automatic Screen Lock" is set to ON. 5. For "Lock screen after blank for", select "Screen Turns Off". 6. In the left-hand menu, select Power. 7. Under Power Saving -> Blank screen, select a value less than 15 minutes. Ubuntu 20.04 1. From the upper-right drop-down menu, click the Settings icon. 2. In the left-hand pane, select Privacy -> Screen Lock. 3. For "Blank Screen Delay", select a value less than 15 minutes. 4. Set "Automatic Screen Lock" to ON. 5. For "Automatic Screen Lock Delay", select "Screen Turns Off". 6. Set "Lock Screen on Suspend" to ON. 7. Screen should lock within 15 minutes if the system is idle. . On mac: 1. Choose \[System Preferences] from the Apple menu. 2. Click Desktop & Screen Saver. 3. Click the Screen Saver tab. 4. Adjust the "Start after" dropdown to 15 minutes or less. 5. Also make sure that on \[General] tab, the pull down menu is set to "immediately". On Windows: 1. Open \[Lock screen settings]. 2. Scroll down and click on "Screen saver settings". 3. Make sure the wait time is less than or equal to 15 minutes. . On linux: Ubuntu 18.04: 1. From the upper-right drop-down menu, click the Settings icon. 2. In the left-hand pane, select Privacy. 3. Click on ScreenLock 4. For "Lock screen after blank for", select "Screen Turns Off". 5. In the left-hand menu, select Power. 6. Under Power Saving -> Blank screen, select a value less than 15 minutes. Ubuntu 20.04 2. From the upper-right drop-down menu, click the Settings icon. 3. In the left-hand pane, select Privacy -> Screen Lock. 4. For "Blank Screen Delay", select a value less than 15 minutes. 5. For "Automatic Screen Lock Delay", select "Screen Turns Off". If you have questions. is here to help. If you have technical issues with the Sprinto platform or Dr. Sprinto, please reach out to their support team at . # New Sprinto App Navigation UI Overview We’re excited to introduce the enhancements we bought to the Sprinto User Interface (UI)! This update enhances dashboard navigation by reorganizing compliance sections under relevant categories for a more seamless experience. Note: This update only affects Sprinto’s core navigation UI. The compliance modules (e.g., Access, People, Policies) retain their existing features, functionalities, and navigation.
Menu OptionDescription
DashboardProvides a real-time overview of your compliance health, pending tasks, and audit activities.

Audits


A centralized space to plan, conduct, and manage internal or external audits. Collaborate with your team, collect evidence, and communicate with auditors. Learn more in our Audit documentation.
PoliciesManage your organization's policies and security documents: Configure, update, and track policy versions. See our Policies documentation for details.
RisksIdentify, assess, and mitigate organizational risks. Maintain an up-to-date risk register. See our Risk documentation for more details.
ComplianceHouses Frameworks, Controls, and Resources. Manage compliance frameworks, mapped security controls, and shareable documents like Letters of Engagement or reports.
Data LibrarySprinto’s most comprehensive compliance space contains sub-modules like People, Training, Staff Devices, and more. Each module supports specific compliance requirements. See our detailed documentation.
TrustThe Trust section comprises Trust Center, Responsible Disclosure, and Questionnaires. Refer to our detailed documentation for each section to learn more.
Settings
Manage essential app functionalities like Integrations, Checks, Security Controls, Zones, Company Profiles, Integrations, and more.
This update improves navigation across the Sprinto app, making it more intuitive and organized. However, each module's core functionalities, features, and workflows remain unchanged. Please get in touch with our [support team](mailto:www.support@sprinto.com) if you have any queries related to the new app navigation menu or need assistance. # User Management The User Management module in Sprinto enables administrators to control who can access specific features and tasks across the platform. It is designed to help you delegate responsibilities securely and efficiently by assigning roles and permissions to both admin and non-admin users. Whether you're managing internal compliance tasks or coordinating with external stakeholders, User Management provides the tools to maintain clarity, accountability, and control. Use this section to learn how to: * Assign checks to non-admin users (collaborators) * Manage and revoke collaborator access * Enable task resolution through the employee portal # User Management (Collaborator) Learn how to assign, manage, and revoke collaborator access in Sprinto for seamless task delegation and compliance tracking. ## Overview This guide provides comprehensive instructions on managing collaborators in Sprinto, including assigning checks, revoking access, and resolving assigned checks. Collaborators are non-admin users who have specific permissions that enable them to access and complete assigned tasks without requiring full admin privileges. This streamlined approach ensures enhanced collaboration and task management without compromising security or administrative control. Collaborators play a crucial role in Sprinto by handling specific tasks and compliance activities delegated to them by admin users. By granting collaborator access, non-admin users can effectively participate in the compliance management process without needing complete administrative rights. This division of responsibilities fosters a more efficient and secure collaboration environment within the organisation. *** ## Add a Collaborator Before you begin, ensure you are logged into the Sprinto Admin Portal with appropriate credentials. Having administrator access is necessary to add or manage collaborators within the portal. 1. Navigate to **Dashboard > Tasks**. The Tasks tab will display all available checks and their current assignments. 2. Hover over the **Sprinto check assignment** column and click the edit icon to start assigning the check. 3. From the **Assigned to** drop-down menu, carefully search for the non-admin user listed under the **All other staff** category. This list includes all staff members who do not have administrative rights. 4. Click **Make collaborator & assign** next to the name of the staff member. This action grants collaborator access and assigns the selected check. 5. Click **Save changes** to finalise the assignment. The designated user will automatically receive an email notification containing the access link and task details. *** ## Revoking Collaborator Access To revoke collaborator access, follow these steps: 1. Navigate to **Settings > Teams** and select the **All members** tab from the list. This section displays a comprehensive list of current collaborators within the organisation. 2. Scroll through the list to find the specific collaborator whose access you wish to remove. 3. Click the **Remove** button next to the user's name. A confirmation dialog will appear to verify your intent. 4. Click **Remove** again in the pop-up dialog to confirm and finalise the revocation of collaborator access. By revoking access, the user's permissions will be instantly updated, removing their ability to manage or view the previously assigned tasks. *** ## Assigning Sprinto Checks to Collaborators Assigning checks to collaborators is an efficient way to distribute compliance tasks among non-admin users. To do so, follow these steps: 1. Log into the **Sprinto Admin Portal** and navigate to **Dashboard > Tasks**. Alternatively, visit the **Configure Checks** page to view all available checks. 2. Identify and select the specific task you wish to assign. You may utilise the search bar or filters for quicker navigation through the tasks. 3. Click **Manage** from the task details drawer, which opens a menu of assignment options. 4. In the drop-down menu, select **Mark collaborator & assign** next to the chosen user. Non-admin users are listed under the **All other staff** category. 5. Click **Save Changes** to complete the assignment. An automatic email notification will be sent to the collaborator, providing them with details about the assigned task. *** ## Resolving Assigned Checks as Collaborator 1. Log into the **Sprinto Employee Portal** using your credentials. 2. Access the assigned tasks through the email notification link or directly via the portal dashboard. 3. Once on the dashboard, click **View** next to any pending tasks to access the details. 4. Carefully review the assigned check, including linked documentation if available, to understand the requirements. 5. Click **Fix it** to begin the resolution process. Follow the guided steps to complete the necessary actions. If the task is marked as a special case, update it accordingly by marking it as such. 6. Once resolved, ensure to mark the task as completed to update the status. Note: The task dashboard is only accessible when there are pending tasks to address. *** ## Support If you encounter any issues or require further assistance, do not hesitate to reach out to the Sprinto support team at . Our team is available to help you with collaborator management and any related concerns. # Check Super Admin Status (Google Workspace) Sign Up can be done by GSuite super-admin. So, how to check SUPER ADMIN STATUS on G-Suite? 1. Go to: 2. Ensure the customer key is entered as ‘my\_customer’ and click “Execute”. If it works (gives 200 status code as a response), the ID has the necessary credentials. ![](https://s3.amazonaws.com/cdn.freshdesk.com/data/helpdesk/attachments/production/72013662907/original/haHq9vEHB_WNtsl8Sp45vagGCv-pmn2khg.png?1657010277) # Control Health Dashboard Track the overall compliance posture, monitor control readiness, and review pending work across all compliance areas from Sprinto’s main dashboard. The **Control Health Dashboard** provides a real-time view of your organisation’s compliance posture and the health of all configured security controls. It consolidates key information from across Sprinto into a single page, enabling you to: * Monitor readiness percentages for all mapped controls. * Review passing, failing, due, and critical checks. * Identify pending control setup tasks. * Drill down into specific compliance areas for detailed analysis. You can access the Control Health Dashboard by: 1. Logging in to the Sprinto dashboard. 2. Navigating to **Dashboard** → **Control health**.
By default, the dashboard displays readiness data for **All Zones**, but you can switch to a specific zone using the zone selector. *** #### Dashboard Actions **1. Monitor overall control readiness** * **Readiness percentage** shows the average readiness of all configured controls. * **Control readiness timeline** visualises readiness trends over the last 7, 15, or 30 days. * **Controls set up vs pending setup** helps track configuration progress. **2. Review check performance** * **All checks** widget summarises passing, failing, critical, and due checks across all areas. * View automation coverage percentage to see how much is monitored automatically via Sprinto integrations. * The **Checks assigned to you** widget highlights your pending tasks by severity. **3. Browse controls by area** * View readiness scores for each compliance area (e.g., *People*, *Policies*, *Risks*, *Trainings*). * Click an area to open the **Controls mapped to \[Area]** panel. * Within the panel, controls are categorised as: * **Needs Setup** – not yet configured. * **Needs Work** – configured but with failing or pending tasks. * **100% Ready** – fully configured with no pending issues. **4. View control details** * Click **View details** for a control to open its dedicated page in the relevant Sprinto product section. * Review assigned Sprinto checks, readiness percentage, and mapped framework details. *** #### Readiness Calculations Sprinto uses the following formulas to calculate readiness: * **Framework readiness** ``` Sum of readiness % for all compliance areas ÷ total compliance areas ``` * **Compliance area readiness** ``` Sum of readiness % of mapped controls ÷ total mapped controls ``` * **Control readiness** ``` Sum of readiness % of mapped checks ÷ total mapped checks ``` *(Considered 100% if mapped with organisational policy evidence or external evidence)* * **Sprinto check readiness** ``` (Passing + Due + Critical instances) ÷ (Total instances) ``` *** #### Best Practices * Prioritise controls in **Needs Work** or **Needs Setup** status to improve compliance scores quickly. * Address failing checks early to avoid escalation to critical compliance risks. * Regularly monitor the readiness trend to ensure sustained compliance posture. *** #### Frequently Asked Questions **1. What does the readiness percentage represent?**\ The readiness percentage reflects the average health of all configured security controls, based on the readiness of their mapped Sprinto checks. **2. How is “Needs Setup” different from “Needs Work”?** * **Needs Setup** – The control is not yet configured with the required owner, mapped checks, or framework association. * **Needs Work** – The control is configured but has failing or pending check instances that require action. **3. Can I view readiness for a specific zone?**\ Yes. Use the zone selector at the top of the dashboard to filter the view for a specific zone. **4. How do I find the details for a failing control?**\ Click the compliance area from the “Browse controls by area” list, then select **View details** for the specific control to open its full details page. **5. What does 100% Ready mean?**\ A control is considered 100% Ready when all mapped checks are passing, or when organisational policy evidence or external evidence is mapped to it. # Continuous Risk Monitoring Monitor risks in real time, assess treatment effectiveness, and identify risks requiring attention from a centralised dashboard in Sprinto. The **Continuous Risk Monitoring** tab in Sprinto allows you to proactively monitor risks, evaluate the effectiveness of treatments, and focus on those that require immediate action. To access Continuous Risk Monitoring: 1. Log in to the Sprinto dashboard. 2. Navigate to **Dashboard** → **Continuous Risk Monitoring**.
From this page, you can: * View the total number of approved risks in your risk register. * Track **average inherent risk**, **average residual risk**, and **average effective residual risk**. * Measure **average treatment effectiveness** for your organisation’s risk portfolio. * Review a **summary of risks by treatment effectiveness**, grouped by category (for example, *Cybersecurity*). *** #### Dashboard Actions **1. View overall risk posture** * The summary cards display key metrics: * **Average inherent risk** – risk level without any mitigation or controls. * **Average residual risk** – remaining risk after mitigation. * **Average effective residual risk** – residual risk adjusted for treatment performance. * **Average treatment effectiveness** – overall percentage indicating how well risk treatments are performing. **2. Drill down into risk details** * Click a risk category to view treatment effectiveness for individual risks. * Each risk entry displays: * **Risk name and ID** (for example, *CRK 77.1: Data Breach*). * Description of the risk. * Average treatment effectiveness percentage. * Controls applied to mitigate the risk. * Number of checks monitoring each control, with readiness percentages. * Associated risk treatment tasks and their completion status. **3. Review control and task readiness** * Expand a control to view all mapped checks and their individual readiness status. * Track pending tasks related to risk treatment directly from the drawer view. **4. Identify improvement areas** * Use readiness percentages to quickly identify underperforming controls or incomplete tasks. * Focus efforts on failing or low-readiness areas to improve overall treatment effectiveness. *** #### Best Practices * Regularly review risks with low treatment effectiveness to ensure timely remediation. * Use the readiness breakdown to prioritise resources where the most impact can be made. * Keep treatment tasks up to date to prevent risk posture degradation over time. # Task Dashboard View, filter, and manage all pending compliance tasks across Sprinto from a single, centralised dashboard. The **Task Dashboard** in Sprinto provides a centralised view of all pending tasks across your organisation. It helps you track, prioritise, and take action on tasks from multiple Sprinto modules, including People, Policies, Risks, Infrastructure, Reviews, Vendors, and more. You can access the Task Dashboard by: 1. Logging in to the Sprinto dashboard. 2. Navigating to **Dashboard** → **Tasks**.
The Task Dashboard displays: * **Task counts** by category. * **Criticality** levels – *Failing*, *Critical*, and *Due*. * **Assignment details** – who is responsible for each task. * **Time to fix** indicators to help prioritise urgent items. Three main views are available: * **All tasks** – shows every pending task across Sprinto. * **Assigned to me** – shows only tasks assigned to you. * **Escalated to me** – shows tasks that have been escalated to you for urgent attention. *** #### Dashboard Actions From the Task Dashboard, you can: **1. Filter tasks** * **By zone** – choose between *All zones* or a specific zone in your organisation. * **By role** – filter by Company, All staff, or specific security roles (for example, *InfoSec Officer*, *Privacy Officer*, *People Operations Person*). * **By area** – narrow down tasks by functional areas such as *Access*, *Workflow checks*, *Change management*, *Company products*, *Staff devices*, and *Infrastructure*. * **By status** – view only tasks that are *Due*, *Critical*, or *Failing*. **2. Search and export** * Use the search bar to find specific tasks. * Download a report of all pending tasks for record-keeping or review. **3. View and manage task details** * Click on any task to open its detail view. Depending on the task type, you can: * Redirect to the relevant Sprinto product area. * Complete certain tasks directly within the dashboard (for example, reviews and workflow checks). * Upload evidence to resolve a task. * Review mapped controls, mapped zones, and associated areas. **4. Assign or escalate tasks** * Assign tasks to relevant team members. * Set escalation to another role or user to ensure high-priority items are addressed promptly. **5. Track deadlines** * Monitor due dates and “time to fix” estimates to prioritise effectively. # Overview Manage compliance, internal, and custom audits effortlessly with Sprinto’s centralised audit management platform. Sprinto’s **Audit** module empowers your organisation to manage audits confidently and systematically. Whether you're undergoing a compliance audit, internal assessment, or external review, the Audits section centralises all related activities—enabling InfoSec teams, auditors, and business stakeholders to collaborate effectively. This module supports both **partner audits**, which are linked to specific frameworks (such as SOC 2, ISO 27001, or GDPR), and **custom audits**, which can be tailored to suit internal policies or third-party requests.
*** ### Key Benefits * **Streamlined management** of audit tasks, deadlines, and responsibilities. * **Real-time visibility** into audit progress and evidence collection. * **Automated documentation** and reporting, reducing manual overhead. * **Seamless auditor collaboration**, with granular access control. * **Integrated with controls and evidence** across your systems via Sprinto’s compliance engine. *** ### Types of Audits in Sprinto
Audit TypeDescription
Partner AuditTied to a compliance framework (e.g. SOC 2, ISO 27001). Uses pre-defined requirements mapped to controls.
Custom AuditFlexible audit setup, allowing you to define your own checklist or respond to ad hoc auditor requests.
{% hint style="info" %} You can access **Custom Audits** only if you are on **Plan 3 or Plan 4**. Users on **Plan 1 or Plan 2** have access to **Partner Audits** only. {% endhint %} *** ### Core Components
ComponentDescription
Audit EventsInstances that represent a scheduled audit (e.g. “SOC 2 Type II – Q1 2025”).
Evidence CollectionThe process of uploading, verifying, and mapping documents to audit requirements.
TasksAssigned action items for evidence owners and stakeholders.
Audit DashboardA visual interface that provides a high-level view of audit progress and status.
Lifecycle ReportingInsights into audit stages, completion rates, and findings to support internal reviews and board reporting.
*** ### Use Cases
ScenarioHow Sprinto Audits Help
Preparing for a scheduled SOC 2 auditUse the integrated audit workflow to track evidence, manage tasks, and collaborate with your auditor.
Responding to a customer security assessmentCreate a custom audit event and upload specific documents requested by the customer.
Running internal policy auditsConfigure a custom audit to validate internal controls and processes periodically.
Managing multi-framework compliance auditsConduct and track audits across frameworks like ISO, HIPAA, and GDPR in a centralised manner.
Tracking audit outcomes and stakeholder tasksMonitor progress, assign responsibilities, and generate reports for leadership and board presentations.
*** ### When to Use the Audit Module Use the Audit module when: * You’re preparing for a framework-based audit like SOC 2 or ISO 27001. * You need to conduct internal audits for governance and risk management. * A customer or third party requests evidence or assessment documentation. * You want to track the status of ongoing and completed audits in one place. # How it Works Understand the end-to-end flow of how to manage audits in Sprinto. From setting up an audit event to tracking tasks and outcomes, Sprinto’s audit workflow ensures you're always in control and audit-ready. *** ### Workflow Given below is a complete end-to-end flow of how an Audit works.
#### Step 1: Create an Audit Event Start by creating a new audit event—this represents a scheduled audit, such as "SOC 2 Type II – Q1 2025". You can choose between: * **Partner Audit:** Pre-configured based on your selected framework (e.g. SOC 2, ISO 27001). * **Custom Audit:** Fully flexible, suited for internal reviews or customer questionnaires. {% hint style="info" %} * You can duplicate past audits to maintain consistency. * Add relevant metadata like the audit period, zone, and auditor. {% endhint %} *** #### Step 2: Assign Tasks and Upload Evidence Once your audit event is created, Sprinto automatically maps relevant controls and requirements to the audit. * Assign tasks to evidence owners across your organisation. * Upload supporting documents and link them to the mapped requirements. * Maintain status updates across these tasks for better visibility. {% hint style="info" %} * Use pre-mapped controls and evidence from existing integrations. * The same document can be reused across multiple requirements where applicable. {% endhint %} *** #### Step 3: Internal Review and Auditor Access Before submission, perform an internal review to ensure all requirements are complete. * Mark requirements as "Ready for Audit". * Share secure, read-only access with your auditor. * Use the auditor view to simulate what they will see. {% hint style="info" %} * You can revoke auditor access at any time. * Sprinto maintains an audit log of all shared content for transparency. {% endhint %} *** #### Step 4: Monitor Audit Progress and Report Outcomes Track audit progress using the Audit Dashboard and Lifecycle Reporting. * View overall completion status and requirement breakdowns. * Identify pending tasks and overdue items. * Export reports for internal reviews or board reporting. {% hint style="info" %} * Use the Lifecycle Reporting section to monitor each phase—from evidence collection to final audit closure. * Reports are available for both partner and custom audits. {% endhint %} # Dashboard Actions # Create an Audit (Plans 1 and 2) Learn how to create audits in Sprinto, define audit periods, and add requirements with ease. ### Prerequisites Before you begin: * You must have the **Admin** role in Sprinto. * Your compliance framework should be connected if you're creating an integrated audit. * Relevant zones and integrations should already be configured. *** ### Create an Audit These audits are pre-configured audits tied to a compliance framework (e.g. SOC 2, ISO 27001). These audits automatically map framework requirements to Sprinto’s control set. #### Steps: 1. **Navigate to** **Audits** from the left navigation menu. 2. **Click** **Plan new audit.** 3. **Fill in audit details** in the "Plan an audit" screen: * **Zone**: Select the operational zone the audit applies to (e.g. Pacific). * **Audit Type**: Choose **External** or **Internal**, depending on whether it’s conducted by an external auditor. * **Framework**: Select the applicable compliance framework (e.g. SOC 2). * **Standards for the framework**: Choose one or more control categories (e.g. Security, Confidentiality). {% hint style="info" %} Once the audit is created, the framework cannot be changed. {% endhint %}
4. **Set the evidence collection period**: * Select an **evidence collection start date** using the calendar picker. * Choose the **duration** (12, 6, or 3 months), or select **Custom** to define your own period. * The **end date** will automatically adjust based on your selection, and can be modified if needed.
5. **Click “Start Audit”** to generate the audit and proceed to the requirement mapping stage.
Custom Audit Drawer
*** ### Add Your Audit Requirements After you create your audit, you’ll land on the **Summary** page. At this stage, no requirements are linked to your audit. To begin defining the scope of what the audit will cover, you must add audit requirements. #### To Add Audit Requirements 1. On the **Summary** page, locate the **Requirements** panel. 2. Select **Add**.
3. In the side drawer, choose one of the following methods: #### Upload Your Requirements Use this method to upload your own list of audit requirements using a CSV file. **To Upload a CSV File** 1. In the drawer, select **Upload your requirements**. 2. Click Download CSV template to download the template. 3. Fill in the required details and upload the file into the uploader.
3. Review the uploaded requirements. * Sprinto displays a preview of the parsed file. * Any issues, such as missing fields or formatting errors, are shown with inline guidance.
4. Make necessary corrections if validation errors appear. 5. Select **Save** to confirm and import your requirements. {% hint style="info" %} You can upload additional files later or delete and re-upload files as needed. {% endhint %}
*** #### Add Requirements by Framework Criteria Use this method to select specific requirements from a compliance framework (for example, SOC 2 or ISO 27001). **To Add Framework-Based Requirements** 1. In the drawer, select **By framework criteria**. 2. Choose a framework and the applicable standards (such as Security or Confidentiality).
3. Use the search or scroll to locate the relevant criteria. 4. Select the checkboxes next to the requirements you want to include. 5. Select **Save** to confirm. {% hint style="info" %} Sprinto auto-populates framework-based requirements with instructions and metadata, where available. {% endhint %}
*** #### Add Requirements by Controls Use this method to convert existing controls into audit requirements. **To Use Existing Controls** 1. In the drawer, select **By controls**. 2. Choose a framework to filter available controls.
3. Tick the checkboxes next to the controls you want to convert. 4. Select **Add** to confirm. 5. Your selected controls are added as audit requirements with mapped descriptions. {% hint style="info" %} This method works best if your controls are already configured in Sprinto. {% endhint %}
### What’s Next? After creating the audit: * Monitor completion status via the Audit Dashboard. * Share access securely with auditors when you're ready. # Create an Audit (Plans 3 and 4) Learn how to create Partner or Custom audits in Sprinto, define audit periods, and add requirements with ease. Sprinto enables you to create and manage both **integrated** and **custom** audits from a unified interface. This guide walks you through the steps required to set up each type of audit. *** ### Prerequisites Before you begin: * You must have the **Admin** role in Sprinto. * Your compliance framework should be connected if you're creating an integrated audit. * Relevant zones and integrations should already be configured. *** ### Create an Automated Audit Integrated audits are pre-configured audits tied to a compliance framework (e.g. SOC 2, ISO 27001). These audits automatically map framework requirements to Sprinto’s control set. #### Steps: 1. **Navigate to** **Audits** from the left navigation menu. 2. **Click** **Plan new audit** and select **Automated Audit**.
3. **Fill in audit details** in the "Plan an audit" screen: * **Zone**: Select the operational zone the audit applies to (e.g. Pacific). * **Audit Type**: Choose **External** or **Internal**, depending on whether it’s conducted by an external auditor. * **Framework**: Select the applicable compliance framework (e.g. SOC 2). * **Standards for the framework**: Choose one or more control categories (e.g. Security, Confidentiality). {% hint style="warning" %} #### Important Once the audit is created, audit type and framework cannot be changed. {% endhint %}
4. **Set the evidence collection period**: * Select an **evidence collection start date** using the calendar picker. * Choose the **duration** (12, 6, or 3 months), or select **Custom** to define your own period. * The **end date** will automatically adjust based on your selection, and can be modified if needed. 5. Toggle the **Auto-schedule next audit** switch if you wish to automatically create a new audit with the same duration when this audit is complete. 6. **Click “Start Audit”** to generate the audit and proceed to the requirement mapping stage. *** ### Create a Custom Audit Use custom audits in Sprinto to conduct internal reviews, respond to customer questionnaires, or manage non-framework-based assessments. This option allows you to define your own set of audit requirements from scratch. #### Steps 1. **Go to** **Audits** from the left-hand navigation menu. 2. **Select** **Plan new audit** in the top-right corner. 3. In the audit type selection screen, **choose** **Custom audit**.
Audit Type Selection
4. **Choose the audit type**: * Select **External** if the audit will be performed by an external auditor. * Select **Internal** if the audit will be conducted within your organisation.\ The explanatory text will adjust automatically based on your selection. 5. **Select an auditor** (optional for internal audits): * Use the dropdown list to choose an existing auditor (for example, EY, Deloitte, or KPMG). * If the auditor is not listed, type the name and select **Add** to include them manually. 6. **Configure the evidence collection period**: * Select a **start date** for the evidence collection using the calendar picker. * Choose a **collection duration**—12 months, 6 months, 3 months, or select **Custom** to define your own range. * The **end date** will be calculated automatically and can be edited if needed. 7. Select an engagement to link this audit to an Align engagement to sync requests as audit requirements automatically. 8. Toggle the **Auto-schedule next audit** switch if you wish to automatically create a new audit with the same duration when this audit is complete. 9. **Select** **Start audit** to create the audit and proceed to the next step, where you can add or upload your audit requirements.
*** #### Understand Audit Milestones The audit overview page displays the audit details, mapped frameworks and controls, assigned auditor, and the current audit stage. The audit progresses through the following milestones: **1. Audit Plan** This stage confirms that the audit has been successfully created and configured. **2. Evidence Collection** During this stage, you collect and organise the evidence required for the audit. You can: * Add audit-specific documents. * Assign or update the auditor. * Review periodic activities that fall within the audit period. * Reschedule periodic activities when required.
*** #### Manage Audit Documents You can attach supporting audit documents directly to the audit. **To add audit documents** 1. In the **Evidence Collection** stage, click **Manage** next to Audit Documents. 2. Choose one of the following options: * **Add from Document Hub** to use an existing approved document. * **Upload a document** to upload a new file.
3. Select the required document. 4. Click **Add document**.
The selected documents become available as part of the audit package. *** #### Manage Periodic Activities Periodic activities that fall within the audit period are automatically associated with the audit. **To review or reschedule periodic activities** 1. Open the **Periodic Activities** tab. 2. Review the status of scheduled checks and monitored checks. 3. Click **Reschedule** to update individual activities. 4. To update multiple activities at once, select **Reschedule All**. 5. Choose new due dates and save your changes.
Sprinto updates the audit schedule based on the revised dates. *** #### Request an AI-powered Pre-audit Evidence Review After the evidence collection period ends, you can request an AI-assisted review of your audit evidence before sharing it with your auditor. {% hint style="info" %} #### Note AI-powered evidence review is available only for **Automated Audits**. This feature is not supported for Custom Audits. {% endhint %} The review helps identify gaps, risks, missing evidence, and potential improvement areas. **To request a review** 1. Navigate to the **Pre-audit Evidence Review** stage. 2. Click **Request AI-powered review**.
3. Review the confirmation message. 4. Click **Request AI-powered review** again to proceed.
Sprinto AI analyses the collected evidence and generates a review report. The report generation process may take a few minutes. *** #### View the AI Evidence Review Report After the review is complete: 1. Navigate to the **Pre-audit Evidence Review** stage. 2. Click **View evidence report**.
The report displays: * Control details * Check titles * Review status * AI-generated findings * Valid and invalid evidence observations If additional changes are made to the audit evidence, click **Regenerate** to create an updated report. *** #### Choose and Share an Auditor After the evidence collection phase is complete, you must assign an auditor before the audit can be shared. Once an auditor has been selected, you can invite auditor contacts to access the audit dashboard and review the collected evidence. **Choose an Auditor** 1. Go to **Audits** and open the audit. 2. In the **Audit milestones** section, click **Choose Auditor**.
3. In the **Select auditor** drawer, search for the audit partner you want to assign. 4. Select the auditor from the search results.
5. Review the confirmation message and click **Confirm**.
The selected auditor is now associated with the audit and appears in the audit summary. {% hint style="info" %} #### Note If you are unsure which audit partner to choose, refer to the [**How to Select an Audit Partner**](/audits/dashboard-actions/selecting-an-audit-partner) guide. {% endhint %} **Share the Audit with an Auditor** After assigning an auditor, share the audit dashboard with the auditor's team so they can review evidence. {% hint style="warning" %} #### Important * You can share an audit with the auditor only after the evidence collection period has ended. If you need to share the audit immediately, update the audit end date to a date that has already passed, then proceed with sharing the audit. * Audit dates can be modified at any time, so you can adjust the audit timeline later if required. {% endhint %} 1. In the **Share with auditor** milestone, click **Share with auditor**.
2. In the **Share audit** drawer, enter one or more auditor email addresses. * To invite multiple auditors, separate email addresses with commas. 3. (Optional) Enable **Include Sprinto Audit Support team in auditor communication** if you want Sprinto's Audit Support team included in audit-related discussions. 4. Click **Share**.
The invited auditors receive an email invitation and can access the audit dashboard and associated evidence. {% hint style="info" %} #### Note Invited auditors can only access the audit dashboard and evidence shared with them. They do not have access to the rest of your Sprinto workspace. {% endhint %} *** #### Complete the Audit Process After reviewing and addressing any findings: 1. Allow the auditor to perform the evidence review. 2. Track progress through **Evidence Review by Auditor**. 3. Complete the audit once all review activities are finished. *** ### Add or Remove Audit Requirements After creating an audit, you can customise the controls and criteria included in the audit based on your organisation's requirements. #### Manage Controls Included in the Audit 1. Go to **Audits** and open the audit you want to configure. 2. On the **Summary** tab, locate the **Frameworks and controls** section. 3. Click the **Edit** icon.
4. In the **Frameworks & controls** panel, select the **Controls included in audit** tab. 5. Review the controls automatically included based on the selected framework. 6. To exclude a control from the audit: 1. Click **Remove** next to the control. 2. In the confirmation dialog, click **Confirm**.
The selected control is removed from the audit and moved to the **Not added in audit** tab. #### Re-add Excluded Controls 1. Open the **Not added in audit** tab. 2. Locate the control you want to restore. 3. Click **Add**.
The control is added back to the audit and appears under **Controls included in audit**. #### Customise Audit Criteria Use the **Criteria view** tab to include or exclude specific audit criteria. 1. Open the **Criteria view** tab. 2. Select the checkbox next to a criteria group to include or exclude all criteria within that group. 3. Expand a criteria group and select individual criteria to customise the audit scope. 4. Click **Save**.
The selected criteria are added to or removed from the audit. #### Notes * Controls are automatically mapped based on the framework selected during audit creation. * Removing a control also excludes its associated evidence from the audit. * Excluded controls can be added back at any time before sharing evidence with the auditor. * Changes made in the **Criteria view** are applied to the audit after you save them. *** After creating the audit: * Monitor completion status via the Audit Dashboard. * Share access securely with auditors when you're ready. # Create a Custom Audit with A-LIGN Learn how to create a custom audit with an A-LIGN engagement and automatically sync audit requirements into Sprinto. If you work with A-LIGN as your external auditor, you can create a custom audit in Sprinto using an existing A-LIGN engagement. Sprinto automatically imports the requests from the selected engagement as audit requirements, allowing you to collect evidence in Sprinto while keeping it synced with A-LIGN. ### Before you begin Before creating an A-LIGN audit, ensure that: * You have integrated A-LIGN with your Sprinto account. For setup instructions, see the [A-LIGN Integration](/integrations/overview/a-lign-integration) Doc. * You have an active A-LIGN engagement. * You have the required permissions to access the A-LIGN engagement. ### Create a custom audit with A-LIGN 1. Log in to your Sprinto account. 2. Go to **Audits**. 3. Click **Plan new audit**.
4. Select **Custom audit**. 5. Enter an **Audit name**. 6. Select the **Audit type**: * **External** * **Internal** 7. Configure the **Evidence collection** period: * Select a **Start date**. * Choose one of the following collection periods: * **12 months** * **6 months** * **3 months** * **Custom**, and specify an end date.
8. Under **A-LIGN engagement**, select the engagement you want to use for the audit. 9. If required, enable or disable **Auto-schedule next audit**. 10. Click **Start audit**.
Sprinto creates the audit and automatically imports the requests from the selected A-LIGN engagement as audit requirements. {% hint style="info" %} #### Note The **A-LIGN engagement** section is available only after you integrate A-LIGN with your Sprinto account. {% endhint %} ### Verify the synced audit requirements After the audit is created, Sprinto syncs the requirements from the selected A-LIGN engagement automatically. 1. Go to **Audits** and open the newly created audit. 2. On the **Summary** tab, review the audit details, including: * Audit name * Audit type * Evidence collection period * Number of synced requirements 3. Select the **Evidence** tab to view the imported audit requirements.
Sprinto automatically creates audit requirements from the requests available in the selected A-LIGN engagement. You can now begin collecting and attaching evidence for each requirement. {% hint style="info" %} #### Note * Requirements are automatically imported from the selected A-LIGN engagement during audit creation. * Any evidence you attach to a requirement in Sprinto is automatically synced to the corresponding request in A-LIGN. * The request IDs displayed in Sprinto correspond to the request identifiers in the selected A-LIGN engagement, making it easier to reference the same request across both platforms. {% endhint %} ### What happens next? After the evidence collection period ends, you can: * Assign an auditor to the audit. * Share the audit dashboard with the auditor. * Collaborate with the auditor throughout the review process. * Complete the audit after all review activities are finished. For more information, see [**Understand Audit Milestones**](/audits/dashboard-actions/create-an-audit-plans-3-and-4#understand-audit-milestones)**.** # Tasks For Audits Create, assign, and complete audit-related tasks in Sprinto using structured workflows for findings, controls, and audit events. Use audit tasks in Sprinto to track follow-ups, assign corrective actions, and manage auditor findings across your audit events. You can create tasks for specific audit events, audit findings, or individual controls. Tasks can be monitored from the **Tasks** tab within the audit or through the **Dashboard** section. *** ### Create a Task for an Audit Event 1. **Log in to the Sprinto Dashboard** and navigate to **Audits** from the left navigation panel. 2. Select the audit event you want to work with. 3. Go to the **Tasks** tab and select **Add task**.
4. Enter the task details: * **Task name** – Provide a descriptive title. * **Assigned to** – Choose an admin from the dropdown (defaults to Infosec Officer). * **Due date** – Set a deadline for completion. * **Description** (optional) – Add task context or instructions. * **Attachment** (optional) – Upload supporting files if needed. 5. Select **Add task** to save.
{% hint style="info" %} Use audit tasks to assign actions for preparation, remediation, or auditor feedback. {% endhint %} *** ### Create a Task for an Audit Finding 1. Navigate to **Audits** from the left navigation panel and select an audit. 2. Go to the **Findings** tab and open the finding that requires attention. 3. Select **Add task.**
4. Fill in the task details as above. 5. Select **Add task** to confirm.
{% hint style="info" %} If your audit currently has no findings, you can still create standard tasks using the Tasks tab. {% endhint %} *** ### Create a Task for a Security Control 1. Go to **Audits** from the main menu and select the relevant audit. 2. Open the **Evidence.**
3. Choose the control that requires follow-up. 4. Select **Add task**.
5. Provide the task details (name, assignee, due date, optional description, and attachments). 6. Select **Add task**.
{% hint style="info" %} This is useful for assigning remediation efforts directly linked to a specific control. {% endhint %} *** ### Mark a Task as Complete 1. Navigate to **Audits > Tasks**, or go to **Dashboard > Tasks** and filter by **Audits**. 2. Select the task you want to close. 3. Add completion details: * **Completion remark** – Optional notes to describe task closure. * **Attachments** – Upload related proof if applicable.
4. Select **Mark task as complete**. Once completed, the related check’s status is updated to **Passing**. *** ### Request for an Evidence Review Here's a short video explaining how to request for an evidence review. {% embed url="" %} ### Share an Audit for Review Here's a short video explaining how to share your Audit dashboard with an external Auditor. {% embed url="" %} ### Mark Audit as Complete Here's a short video explaining how to mark and audit as complete. {% embed url="" %} 1. Log in to the Sprinto Dashboard and navigate to **Audits**. 2. Select the audit you wish to mark as complete from the **Overview** tab. 3. Click **Mark audit as completed**.
*** ### Need Help? For assistance with audit tasks, please contact your Sprinto Customer Success Manager or email [**support@sprinto.com**](mailto:support@sprinto.com). # Update Controls and Criteria for an Automated Audit Learn how to add, remove, and manage controls and criteria within an automated audit in Sprinto. Sprinto allows you to customise the scope of an automated audit by updating the controls and criteria included in the audit. You can: * Remove controls that are not relevant to the audit * Add controls that were previously excluded * Include or exclude entire criteria groups * Select or deselect individual sub-criteria within a framework This helps you tailor the audit scope based on your compliance requirements and auditor expectations. ### Before you begin * Ensure you have access to the Audits module in Sprinto. * Ensure the automated audit has already been created. ### Update controls and criteria for an automated audit 1. Log in to the Sprinto Dashboard and navigate to **Audits**.
2. Select the automated audit that you want to update. 3. In the **Summary** tab, click the **Edit** icon next to **Frameworks and controls**.
4. In the **Frameworks & controls** drawer, use the following tabs to manage the audit scope: #### Controls included in audit This tab displays all controls currently included in the audit.
To remove a control: 1. Locate the control you want to exclude. 2. Click **Remove** next to the control. 3. In the confirmation dialog, click **Confirm**.
The selected control and its associated evidence are removed from the audit and moved to the **Not added in audit** tab. #### Not added in audit This tab displays controls that are currently excluded from the audit. To add a control: 1. Locate the control you want to include. 2. Click **Add** next to the control.
The control is immediately added to the audit and moved to the **Controls included in audit** tab. #### Criteria view This tab allows you to manage criteria and sub-criteria for the selected framework. You can: * Select or deselect an entire criteria group. * Select or deselect individual sub-criteria within a criteria group.
Changes made here automatically update the controls included in the audit. ### Save the changes After updating the controls or criteria: 1. Review your changes. 2. Click **Save**.
A confirmation message appears after the audit criteria are updated successfully. {% hint style="info" %} #### Note * Removing a control excludes its associated evidence from the audit. * You can re-add removed controls at any time from the **Not added in audit** tab. * Updating criteria may automatically increase or reduce the number of controls included in the audit. {% endhint %} # Configure Entities in Audit Evidence Configure which staff members and risk registers are included in audit evidence to control the records displayed during evidence review. Entity configuration allows you to control which records are displayed as evidence during an audit. You can include or exclude specific entities so that only relevant data is surfaced to auditors during the evidence review process. Currently, Sprinto supports configuring the following entities within audit evidence: * Staff * Risk Registers When an entity is included in an audit, its associated records are automatically mapped to applicable audit requirements and evidence sets. {% hint style="info" %} #### Note Entity-based evidence configuration is available as an on-demand feature. To enable this feature for your organisation, contact the Sprinto Support team. {% endhint %} ### Configure entities in audit evidence 1. Log in to the Sprinto Dashboard and navigate to **Audits**. 2. Select the audit you want to configure.
3. Open the **Evidence** tab. 4. Click **Edit entities in evidences**.
The **Choose Entities to display in evidences** drawer opens and displays all supported entities available for configuration. #### Configure staff 1. In the entity drawer, select **Staff**.
2. Choose one of the following options: * Select the checkbox beside **User** to include all staff members. * Select individual staff members to include only specific users. 3. Review the selected staff records. 4. Click **Save**.
The selected staff members are included in the audit evidence and become available wherever staff-related evidence is mapped. #### Configure risk registers 1. In the entity drawer, select **Risk Registers**.
2. Choose one of the following options: * Select the checkbox beside **Risk register** to include all available risk registers. * Select individual risk registers to include specific registers. 3. Review your selections. 4. Click **Save**.
The selected risk registers are included in the audit and their associated records become available as evidence for applicable audit requirements. ### View risk register evidence in audit requirements When Risk Registers are included in an audit, Sprinto automatically maps relevant risk register records to associated controls and requirements. To review the mapped evidence: 1. Navigate to the audit's **Evidence** tab. 2. Select a requirement that contains risk register evidence.
3. Open the requirement to view its details. The requirement page displays: * Mapped evidence sets. * Associated risk assessment records. * Supporting evidence linked to the selected Risk Register. * Related documentation and evaluation details.
If multiple Risk Registers are included in the audit, use the **Risk Register** filter to switch between registers and review evidence records from a specific register. This helps auditors review risk-related evidence without leaving the audit workflow. {% hint style="info" %} #### Notes * Entity configuration is currently supported for **Staff** and **Risk Registers** only. We plan to extend support for more entities soon. * Changes apply only to the selected audit. * Excluded entities are not displayed as part of the audit evidence. * Evidence records are automatically surfaced in applicable requirements when the corresponding entity is included in the audit. * If multiple Risk Registers are included, reviewers can filter evidence by register directly from the requirement view. {% endhint %} # Audit Dashboard States The Revamped Audit Overview in Sprinto gives you a consolidated, real-time snapshot of all your audits. It provides clarity across tasks, findings, messages, and audit stages—helping your team stay compliant and audit-ready. **Access the Audit Overview** 1\. Sign in to your Sprinto Admin account.\ 2\. From the left-hand navigation, select Audits.\ 3\. On the Audits screen, click the Overview tab.
**Overview Layout States** **1. Empty State** Displayed when no audits have been created.
**2. One Audit State** Displays audit status when one audit is present.
**3. Partial State** Displayed when audits are present but lack findings/messages.
**4. Full Overview** Displayed when audits have active tasks, messages, and findings.
**Navigate the Audit Overview** **Audit Status Breakdown** At the top of the Overview tab, a donut chart visualises audits by their stage: Collecting Evidence, Shared with Auditor, Completed, and Archived.
**Findings Overview** Findings are shown by severity to identify and resolve compliance risks.
**Task Summary** View audit tasks classified by status and examine specific tasks.
**Message Threads** Track all open conversations with auditors from the Message Threads panel.
**View the List of Audits** The bottom section contains a searchable, filterable table with metadata for each audit.
**Filters and Search** You can refine the audit list using filters and search.
**Open Audit Details** Click any row in the audit table to open the Audit Details view. **Chart Visibility by Plan** Audit overview visibility is based on your subscription plan:
# Selecting an Audit Partner Find the right audit partner through Sprinto’s accredited network of auditors to match your compliance needs, frameworks, and budget. ### Understand Who Auditors Are Security compliance auditors are independent third-party professionals who assess an organisation’s adherence to recognised security standards and regulations. Similar to financial auditors, they review internal policies, procedures, and systems to evaluate the effectiveness of security controls, risk management practices, and data protection mechanisms. Following an audit, these professionals issue detailed reports that serve as verifiable proof of your organisation’s security posture. Such reports not only establish credibility but also help build trust with customers, partners, and prospective clients. All audit partners available through Sprinto are certified and trained in industry-recognised audit methodologies associated with bodies such as AICPA and ISO. *** ### How to Select the Right Audit Partner Choosing an appropriate audit partner is a critical step in your compliance journey. Sprinto works with a wide network of highly qualified and accredited auditors, including both audit firms and individual Certified Public Accountants (CPAs). The following considerations can help guide your selection: #### 1. **Pricing** Sprinto’s network includes: * **Audit firms** – These are well-known and may appeal to enterprises that require high-recognition names. * **Individual CPAs** – Typically more cost-effective while offering the same level of certification and rigour. Depending on the chosen auditor and framework, audit costs may range between $1,000 and $25,000. Your Customer Success Manager (CSM) can provide specific quotes based on your requirements. #### 2. **Credibility** All auditors in our network are: * AICPA-accredited (for SOC 2 and other U.S.-based frameworks), * IAF-accredited certifying bodies (for ISO standards), or * Recognised authorities in their respective domains. These credentials ensure the validity and acceptance of your audit report. #### 3. **Reputation** Sprinto partners with both individual auditors and globally reputed firms. If your customers include Fortune 500 companies, you may prefer firms such as Deloitte, EY, or KPMG. However, audits conducted by individual CPAs are equally valid and may offer quicker turnarounds at competitive prices. #### 4. **Experience with Sprinto** All auditors in our network are familiar with Sprinto’s platform. Our dedicated auditor dashboard ensures streamlined evidence review, efficient communication, and faster reporting—making the audit experience smoother for both parties. #### 5. **Supported Frameworks** Sprinto audit partners cover a wide range of security and privacy frameworks: * **Multi-framework experts** – Auditors such as Prescient Assurance and CertPro support SOC 2, ISO 27001, ISO 27701, PCI-DSS, HIPAA, GDPR, and HITRUST. * **Specialists** – Firms like Linford excel in conducting FedRAMP and related audits. *** ### Final Considerations Your audit requirements may evolve as your business grows. Sprinto’s diverse partner network is designed to scale with your organisation. The ideal audit partner is one who aligns with your compliance needs, understands your business context, and operates within your budget. We recommend speaking with your CSM or Account Manager to get a tailored recommendation. You can also contact us directly at [**support@sprinto.com**](mailto:support@sprinto.com) for further assistance. # Scoring an Audit Enable your auditors to assign detailed scores and change review statuses for audit requirements using custom scoring fields in Sprinto. Sprinto lets you configure scoring fields—such as grade, score, and maturity level—so that auditors can assess each audit requirement using clear, quantifiable criteria. These fields are added by the admin and appear in the auditor's dashboard once the audit is shared. *** ### Admin View: Set Up Scoring Admins are responsible for defining how auditors score each requirement. You can configure a combination of single-select fields, formula-based fields, or custom fields. #### To set up scoring: 1. Lo in to the Sprinto Dashboard. 2. Navigate to the **Audits** section and select an audit. 3. In the **Summary** tab, scroll to the **Scoring** section. 4. Select **Set up scoring**.
5. Choose fields from the available list or create a new custom field. 6. Use drag-and-drop to reorder the fields. 7. Select **Save**.
{% hint style="info" %} If the audit is already shared with an auditor, changing the scoring fields may overwrite previously submitted responses. A warning message will appear before the changes are applied. {% endhint %} *** #### Supported Field Types
Field NameField TypeDescription
ScoreSingle-selectNumeric scale (e.g. 1 to 5)
GradeSingle-selectNumeric scale (e.g. 1 to 5)
Maturity LevelFormulaComputed from values such as Grade and Score
Control MaturityMulti-selectTags like "Implemented", "Documented", etc.
Other CommentsTextFree-text input for auditor remarks
*** ### Auditor View: Perform Scoring and Change Review Status Once an audit is shared with an auditor, they will be able to: * View all requirements and their related evidence. * Score each requirement using the fields configured by the admin. * Change the review status of each requirement. #### To score a requirement: 1. Log in to the audit using the link shared with you. 2. Navigate to the **Requirements** tab.
3. Select a requirement to open the scoring view. 4. Fill in the scoring fields such as Score, Grade, and Control Maturity. 5. Select **Save**.
#### To change a requirement's status: Auditors can update the status of any requirement after reviewing the evidence. * **Request for information**: Select this if the evidence is insufficient or unclear. This action opens a message thread with the admin. * **Review completed**: Select this to mark the requirement as reviewed and scored. You may also indicate whether the requirement resulted in a minor or major non-conformity.
{% hint style="info" %} Scoring fields must be completed before a requirement can be marked as reviewed. {% endhint %} *** ### Final Audit Score The **Final Audit Score** is automatically computed as the average of all completed scores across requirements. This score provides a quantitative view of the audit's overall performance. *** ### Scoring Status States
StatusDescription
Not StartedNo scoring fields have been configured yet.
In ProgressFields have been configured, but auditors have not scored all requirements.
CompletedAll scoring is completed and statuses are updated.
# Audit Lifecycle Reporting The **Audit Lifecycle Reporting** feature in Sprinto provides structured, data-driven insights for InfoSec teams and senior stakeholders. It helps track progress across audit stages, task ownership, evidence submissions, and auditor findings—across both **Integrated** and **Custom Audits**. *** ### **Access the Audit Lifecycle Report** 1. Sign in to your **Sprinto Admin** account. 2. In the left-hand navigation, select **Reports**. 3. Under **Audit Lifecycle Reporting**, use the dropdown filters to select the relevant **audit** and **zone**. 4. The report loads automatically and displays detailed metrics across the entire audit lifecycle. ![](https://s3.amazonaws.com/cdn.freshdesk.com/data/helpdesk/attachments/production/72147708224/original/lN7vUQSm_vr84iiGadl4eERv6p7faGqIUw.jpg?1746438942) *** ### **Understanding the Audit Lifecycle Report** The report consists of six key sections aligned to various audit phases and team responsibilities. #### **1. Audit Overview** This section offers a high-level summary, including: * Key audit stages * Metadata such as audit type, framework, and zone * A visual progress tracker indicating audit completion status #### **2. Status of Audit Requirements** Displays how audit requirements are distributed across four stages: * **Evidence Collection** * **Internal Review** * **Ready for Audit** * **Audit Completed** Use this section to identify stages that require further action or input. #### **3. Audit Task Summary** Summarises the status of all audit tasks: * **To Do** * **In Progress** * **Completed** Additional insights include: * Percentage of tasks pending * Responsible assignees for incomplete tasks This section helps identify bottlenecks and promote accountability. #### **4. Evidence by Type** Groups collected evidence by submission source: * **Evidence Requests** * **Uploaded Policies** * **Automated Checks** * **Workload Checks** This overview helps managers assess evidence completeness and source dependencies. #### **5. Evidence Requests** Provides visibility into: * All ongoing evidence requests * Team members with the highest number of pending uploads * Team members with the most pending review items This section supports operational clarity and encourages timely resolution of documentation gaps. *** #### **6. Auditor Findings** Findings are categorised by: * **Severity**: Major Non-Conformity, Minor Non-Conformity, and Opportunities for Improvement (OFIs) * **Status**: Open, Reported, Closed You can also track: * Tasks created for each finding * Current task status * Assignees responsible for unresolved issues *** ### **Supported Audit Types** Audit Lifecycle Reports are available for: * **Integrated Audits** – using Sprinto’s standard audit flow * **Custom Audits**, including: * **Entity Risk Level (ERL) Audits** * **Framework-based Criteria Audits** (coming soon) * **Control-based Audits** (coming soon) *** ### **Benefits** Audit Lifecycle Reporting enables your team to move from **reactive audit management** to a **proactive approach**, improving: * Cross-functional collaboration * Accountability * Resolution timelines across audit stages # Audits as an Independent Module Sprinto’s standalone **Audits Module** enables external auditors and organisations to manage and track audits independently—without requiring access to other Sprinto modules. This guide walks you through the initial setup and onboarding flow. *** ### **Step 1: Sign Up Using the Invitation Link** 1. Open the sign-up link shared by your Sprinto contact (CSM or TAM). 2. Provide the following details: * First name * Last name * Work email address * Company name * Customer ID (auto-filled if configured beforehand) 3. Select **Sign up** to continue. > **Note:** The form is pre-filled with your plan, frameworks, and features. These cannot be edited during sign-up. *** ### **Step 2: Log In and View the Welcome Screen** 1. Log in using your registered email address and password. 2. Upon successful login, you will be taken to a welcome screen confirming your account setup. *** ### **Step 3: Complete the Guided Onboarding** After logging in, you will be taken through a **Quick Start** onboarding flow. Follow these steps: 1. **Enter Company Details** – Provide organisation metadata such as name, size, and location. 2. **Invite Team Members** – Add internal users and auditors. Assign appropriate roles (Admin, Editor, or Collaborator). 3. **Assign Tasks** – Allocate audit-related tasks to specific users. 4. **Confirm Frameworks** – Frameworks are automatically enabled. Review and confirm the selection. *** ### **Step 4: Access the Audit Dashboard** Once onboarding is complete, you are redirected to the **Audits > Overview** page. This dashboard gives you visibility into: * Open and assigned audit tasks * Evidence requests from auditors * Status indicators for task completion > **Note:** This standalone module does not support zones or automation-based monitoring. *** ### **Step 5: Plan and Launch an Audit** To start an audit: 1. Select **Plan New Audit** from the top-right corner of the overview page. 2. Choose your preferred audit type: * **ERL Upload** – Upload an Evidence Request List manually. * **Audit by Framework Criteria** – Select specific criteria from a framework. * **Audit by Controls** – Choose individual controls to audit. 3. Specify the audit period, assign audit owners, and begin collecting evidence. # Frequently Asked Questions Get clear answers to frequently asked questions about audit setup, management, and workflows in Sprinto. Find answers to common questions about creating, managing, and completing audits in Sprinto. *** #### 1. What types of audits can I create in Sprinto? Sprinto supports two types of audits: * **Partner audit** – Pre-configured audits based on compliance frameworks (e.g. SOC 2, ISO 27001). These are typically used by organisations on Plan 1 and Plan 2. * **Custom audit** – Fully configurable audits where you define your own requirements. Available for Plan 3 and Plan 4 users. *** #### 2. How do I know which audit creation flow applies to me? The flow depends on your Sprinto plan: * **Plan 1 & 2:** You’ll see a simplified Partner audit setup without an audit type selection. * **Plan 3 & 4:** You’ll see a forking drawer with the option to choose either a Partner or Custom audit. *** #### 3. Can I change the audit type or framework after the audit is created? No. Both **audit type** and **framework** become locked once the audit is created. *** #### 4. Can I edit the evidence collection period after creating the audit? Yes, but only if the audit has not been shared with the auditor. Once shared, the start and end dates become non-editable. *** #### 5. Can I remove a requirement after it is added? Yes, but the method depends on how the requirement was added: * **CSV upload** – Remove the file from the Requirements tab. * **Framework criteria** – Use the delete icon in the edit screen. * **Controls** – Deselect the control and update the audit. Requirements cannot be removed once they are marked **Audit Complete**. *** #### 6. Can I add more requirements after audit creation? Yes. You can return to the **Requirements** tab and select **Add** to include new requirements using any of the available methods. *** #### 7. What actions become restricted after an audit is shared? Once the audit is shared with an auditor: * You can no longer change the auditor or evidence collection dates. * You cannot remove or modify requirements marked **Ready for audit** or higher. * Evidence uploads are locked once requirements are audited. *** #### 8. Can I share the audit multiple times? No. You can only share the audit once. However, you can update the evidence or task owners before sharing, and the auditor will see the latest state. *** #### 9. How do I track audit progress? Use the **Audit Dashboard** to view milestones, and the **Requirements** tab to check the status of each requirement (e.g. Collecting Evidence, Internal Review, Ready for Audit). *** #### 10. Can my auditor make changes in Sprinto? No. Auditors receive a read-only view of the audit. They can leave comments (if enabled), but cannot make edits. *** #### 11. What is an A-LIGN engagement? An A-LIGN engagement is the audit project created in A-LIGN. Sprinto uses the selected engagement to import audit requests as requirements. *** #### 12. What happens if I do not select an A-LIGN engagement? Sprinto cannot sync requests from A-LIGN. To create an audit with automatic requirement syncing, you must select an A-LIGN engagement. *** #### 13. Can I add evidence in Sprinto? *** Yes. Attach evidence to the imported requirements in Sprinto. The evidence is automatically synced to the corresponding request in A-LIGN. *** #### 14. Will updates in A-LIGN automatically create new requirements in Sprinto? Sprinto imports the requests available in the selected engagement when the audit is created. Subsequent syncing behaviour depends on the integration capabilities available for your organisation. # Glossary Explore key audit terms and definitions used in Sprinto to better understand audit workflows and compliance actions. Use this glossary to familiarise yourself with key terms related to audits in Sprinto.
TermDescription
AuditA structured process for assessing compliance with a specific framework or internal requirement.
Partner AuditA pre-configured audit based on a recognised framework (e.g. SOC 2, ISO 27001), typically available to Plan 1 and 2 users.
Custom AuditA flexible audit type where you define your own requirements and scope. Available to Plan 3 and 4 users.
FrameworkA standard or regulation against which your organisation is being audited (e.g. GDPR, ISO 27001).
RequirementA specific control, standard, or checklist item that must be satisfied to complete an audit.
EvidenceDocumentation or data used to support compliance with a specific requirement.
TaskAn action assigned to a team member to collect or submit evidence for a requirement.
Audit StatusThe current lifecycle stage of the audit (e.g. In Progress, Shared with Auditor, Completed).
Requirement StatusThe progress stage of an individual requirement (e.g. Pending, In Review, Ready for Audit, Audited).
Evidence Collection PeriodThe defined time range during which evidence must be collected for the audit.
AuditorThe person or organisation reviewing and validating your audit requirements and evidence.
Summary PageThe main dashboard of an audit where you can view and edit high-level audit details.
Requirements TabA dedicated tab where you can view, add, edit, or remove audit requirements.
ControlsSecurity or compliance practices implemented in your environment, which can be mapped to audit requirements.
CSV UploadA method for importing audit requirements in bulk using a formatted spreadsheet file.
Audit DashboardA consolidated view showing progress across audits, tasks, and requirement statuses.
Share with AuditorA function that creates a read-only view of the audit for the auditor to review submitted evidence.
# Evidences Manage and centralise all your audit-ready documentation in Sprinto with metadata, version control, and seamless evidence tracking. The **Evidences** section in Sprinto provides a centralised view of all artefacts required to demonstrate compliance. Whether collected automatically, uploaded manually, or sourced from policy and workflow checks, evidence in Sprinto helps teams substantiate their adherence to security and regulatory controls. Sprinto classifies evidence into two primary types: * **Automated evidence** – Captured directly via Sprinto’s integrations and platform checks. * **Uploaded evidence** – Includes files uploaded manually, through workflows, evidence requests, or policy documents. This unified space ensures teams can easily access, organise, and manage audit-relevant information with clarity and control. *** ### What is evidence in Sprinto? In Sprinto, an *evidence item* is a standalone file or link—such as a PDF, spreadsheet, screenshot, or system log—that verifies a control is in place or a requirement has been met. Each item: * Is version-controlled * Can include custom metadata * May be linked to audit items or mapped to controls * Can be reviewed and updated, depending on audit status *** ### Use Cases
Use caseDescription
Centralise audit documentationStore all evidence—manual uploads, workflow submissions, and system checks—in one place
Link evidence to audit requirementsMap files to audit checklist items for streamlined compliance
Import existing documentationUpload existing evidence from tools such as SharePoint or Quickbase
Classify and groupUse metadata fields (e.g. evidence group, department, file type) to organise evidence
Manage versionsTrack changes with version history and overwrite outdated submissions
Enable review flowsAssign reviewers and manage pending uploads for better control
Filter and searchLocate relevant evidence quickly using filters, tags, and metadata fields
*** ### Key features #### Central evidence dashboard Access all evidence via a single interface with tabs for: * Automated checks * Uploaded files * Workflow checks * Policy documents * Evidence requests All views follow a consistent flat-table layout, enabling filters, bulk actions, and visibility across evidence types. #### Metadata and custom fields Enhance classification with metadata such as: * Evidence name and identifier (e.g. `EVD-001`) * Collected date * Evidence group * Custom fields (select, multi-select, label, date) Editable fields may be managed individually or in bulk. #### Bulk upload with metadata Upload multiple files at once and configure metadata in a preview table before saving. #### Review and approval Enable reviewers for evidence requests. Items may move through the states: `Upload pending`, `Review pending`, and `Completed`. #### Version control Evidence uploads support version history. New versions may be uploaded as replacements, while audit-linked versions remain unchanged for traceability. #### Control and audit mapping Map evidence to one or more controls, or attach it to relevant audit requirements. *** ### Accessing Evidences To view and manage evidence: * Go to **Audits** in the Sprinto navigation panel * Select the **Evidences** tab From here, users can upload, request, review, and attach evidence based on their role and permissions. *** ### Things to note * Only active audits allow evidence updates. Once an audit is marked as complete, its linked evidence is locked. * Archived evidence cannot be edited or updated in bulk. * Filters and metadata-driven search are available across all evidence types and even within audit workflows. # How it Works Learn how Sprinto simplifies evidence collection, metadata management, and audit mapping with a streamlined, version-controlled workflow. Sprinto enables you to collect, upload, organise, and review evidence files that support your organisation’s compliance with various security frameworks. Evidence can be: * Collected automatically by Sprinto’s platform * Uploaded manually by users * Submitted in response to evidence requests * Added through workflow checks or policy artefacts Each evidence item is versioned, searchable, and can be linked to controls or audit requirements. *** ### Types of evidence in Sprinto
Evidence typeDescription
AutomatedCollected directly via Sprinto’s integrations. No manual input is required.
UploadedAdded manually by users. Can include metadata and be mapped to controls.
WorkflowGenerated from workflow checks configured within Sprinto.
Evidence requestedSubmitted by stakeholders in response to a request.
PolicyGenerated automatically when a policy document is uploaded or linked.
*** ### Evidence lifecycle in Sprinto #### Step 1: Add or request evidence * **Upload manually** by clicking **Upload evidence** and selecting files or links. * **Request evidence** from stakeholders via the **Request evidence** button. * **Upload in bulk** using the multi-file upload feature, assigning metadata in one go. > Each uploaded file becomes an individual evidence item with its own metadata and version history. *** #### Step 2: Assign metadata After uploading, you can assign metadata such as: * **Evidence name** * **Identifier** (auto-generated, e.g. `EVD-001`) * **Evidence group** (e.g. by audit, department, or control) * **Evidence collected date** * **Custom fields** (e.g. department, file type, owner) You can assign metadata: * **Individually**, via the evidence drawer * **In bulk**, via multi-select actions in the table *** #### Step 3: Map to controls or audits * Optionally associate each evidence item with one or more **controls**. * During audit preparation, attach evidence to specific **audit requirements**. {% hint style="info" %} Evidence can be reused across multiple audits and controls. {% endhint %} *** #### Step 4: Review and version * For evidence requests, enable **Review required** and assign a reviewer. * Reviewers can accept or ask for a re-upload. * To update a file, use the **Update evidence** option — Sprinto will create a new version while preserving the previous one. *** #### Step 5: Track and manage Use the **Evidences dashboard** to: * Filter by evidence type, status, or custom metadata * View and manage version history * Edit metadata inline or through the evidence drawer * Archive or bulk update active evidence *** ### Restrictions and best practices * **Evidence cannot be updated** if the associated audit is marked as complete. * **Archived evidence** cannot be edited or updated in bulk. * Use clear and consistent evidence group names to organise files efficiently. * Maintain metadata hygiene for easier filtering and reporting. # Dashboard Actions Here’s a concise, **overview-style draft** for the **Dashboard Actions** main page in the *Evidences* section, following the **Microsoft Writing Style Guide** and using **British English**: *** ## Dashboard Actions The **Dashboard Actions** section helps you perform key evidence management tasks directly from the Evidences dashboard. Whether you're uploading files, assigning metadata, requesting evidence, or tracking review progress—this is your operational hub for handling evidence in Sprinto. You can access all evidence types—**Automated**, **Uploaded**, **Workflow**, **Requested**, and **Policy**—through a unified table interface, enabling efficient filtering, bulk actions, and real-time tracking. *** ### What you can do The Dashboard Actions are grouped into three main categories: #### Create Add evidence to Sprinto in the following ways: * Upload files or links individually or in bulk * Create single or CSV-based evidence requests #### Manage Organise and update your evidence by: * Editing metadata fields and custom tags * Mapping evidence to controls or audits * Managing archived or versioned items #### Complete Finalise evidence-related workflows by: * Uploading evidence against requests * Reviewing submitted items * Attaching evidence to audit requirements *** ### Why it matters Having your evidence on the platform is a prerequisite for running audits on Sprinto. The Dashboard Actions interface ensures that evidence is: * Easily uploadable and requestable * Fully versioned and traceable * Mapped to compliance controls and audit items * Filterable and editable at scale *** ### Tip Use metadata fields like *Evidence group*, *Collected date*, and *Custom tags* to organise your evidence better and locate files faster during audits. # Create Evidences Learn how to create, upload, and request audit-ready evidence in Sprinto using manual, bulk, or CSV-based workflows. Sprinto allows you to add evidence to the platform in three primary ways—manual upload, bulk upload, or through evidence requests. All evidence added becomes a standalone, version-controlled item that can be tagged, reviewed, and linked to audit requirements or controls. This article covers: * Uploading evidence manually * Uploading evidence in bulk * Creating single and bulk evidence requests *** ### Upload Evidence manually Use this method when you want to upload one or more files or links individually. #### To upload evidence manually 1. Go to **Audits > Evidences**. 2. Select **Upload evidence**. 3. In the drawer, do one of the following: * Choose **File** to upload one or more supported files (PDF, CSV, ZIP, etc.). * Choose **Link** to add a shareable link to the evidence file.
4. Enter the following details: * **Evidence name** (required) * **Evidence collected date** * (Optional) Select controls to map using the **Associated controls** dropdown. To map controls: 1. Select the **Associated controls** drop-down and click **Select control**. 2. Select the relevant control categories and choose the controls you want to map to your evidence. 3. Click **Save mapping**.
5. Select **Save**. {% hint style="info" %} Each file uploaded is treated as an individual evidence item. {% endhint %} *** ### Upload Evidence in bulk Use this method when migrating evidence from tools such as SharePoint, Quickbase, or internal drives. #### To upload multiple evidences 1. Go to **Audits > Evidences**. 2. Select **Upload evidence**. 3. Select the File check box if you wish to upload files. {% hint style="info" %} You can upload files with a total size of up to 25 MB or a maximum of 25 files. {% endhint %}
4. Select the link check box if you wish to add links. 1. Click + Add more to add multiple rows of links.
5. Enter the following details: * **Evidence name** (required) * **Evidence collected date** 6. Review all entries and click **Save**. {% hint style="info" %} Each uploaded file receives a unique identifier (e.g. `EVD-001`) that cannot be edited. {% endhint %} *** ### Create a single evidence request Use this method to request evidence from a specific user, such as a department lead or collaborator. #### To create a single evidence request 1. Go to **Audits > Evidences**. 2. Select **Request evidence** > **Create a single evidence request**. 3. Enter the following details: * **Evidence name** * **Details** (optional) * **Request evidence from**: Select a stakeholder or internal user. * **Due date** 4. (Optional) Enable **Review required?** and assign a reviewer. 5. Select **Create request**. The assigned user will receive a task and email notification.
*** ### Create bulk evidence requests via CSV Use this method to generate multiple evidence requests at once. #### To create bulk requests 1. Go to **Audits > Evidences**. 2. Select **Request evidence** > **Create bulk evidence requests via CSV**. 3. Download the CSV template provided.
4. Fill in the required fields: * Evidence name * Details * Email ID of assignee * Due date * Reviewer (if required) 5. Upload the completed CSV file. 6. Preview and review all entries. 7. Select **Save** to send the requests. {% hint style="warning" %} Make sure the email IDs used are already added to your Sprinto account. Invalid entries will result in an error. {% endhint %} *** ### Next Steps Once evidence is created or uploaded, you can: * View and manage it in the **Uploaded** or **Requested** tabs * Assign metadata and map to controls * Track upload and review status from the dashboard # Manage Evidences Learn how to update or archive evidences in Sprinto to keep your audit documentation accurate and organised. Once evidences are added to Sprinto, you may need to make updates or archive items that are no longer relevant. This article explains how to update and archive evidences based on their type. *** ### What can be managed? Only **evidences in the Uploaded** and **Evidence Requested** tabs can be updated or archived. * **Automated, Workflow, and Policy** evidences are view-only and cannot be modified. *** ### Update Evidence You can update evidence if it has been manually uploaded (i.e. appears under the **Uploaded** tab). Updating allows you to change the metadata, associated controls, or the actual file or link. #### To update an uploaded evidence: 1. Go to **Audits > Evidences** and open the **Uploaded** tab. 2. Click the row for the evidence you want to update. 3. In the drawer, select **Update evidence** (top-right). 4. In the update screen, you can: * Edit the **Evidence name** and **Evidence collected date**. * Click **Update** next to the file/link to upload a new version. * Click **Manage** to open the control selector and map or unmap associated controls. 5. After making your changes, click **Update** to save. {% hint style="info" %} The new file or link will replace the existing one. Previous versions will still be available via **View evidence history**. {% endhint %} *** ### Archive Evidence Archiving helps declutter your dashboard while retaining linkage to controls and historical references. Archived evidences are not visible to auditors. #### You can archive evidence from: * **Uploaded tab** * **Evidence Requested tab** *** #### To archive an uploaded evidence: 1. Go to the **Uploaded** tab. 2. Click on the relevant evidence row. 3. In the drawer, select **Archive evidence**. 4. Review the list of associated audits. 5. Click **Confirm** to archive. {% hint style="info" %} Once archived, the evidence remains linked to mapped controls but will no longer appear in audit workflows. {% endhint %} *** #### To archive an evidence request: 1. Navigate to the **Evidence Requested** tab. 2. Click the row of the evidence request you want to archive. 3. In the drawer, click **Archive request** (top-right). 4. Review the impact note—archiving will remove access for auditors. 5. Click **Confirm**. # Search Evidences Quickly find the right audit files in Sprinto using powerful search and filter options across all evidence types. As your compliance programme grows, managing a large volume of evidences becomes essential. The **Search Evidences** feature in Sprinto allows you to quickly locate specific evidences across different categories using filters and keywords. This article explains how to search for and filter evidences in each tab of the **Evidences** dashboard. *** ### Where you can search You can search and filter evidences in all five tabs: * **Automated** * **Workflow** * **Evidence Requested** * **Uploaded** * **Policy** > 🛈 While you can search in all tabs, only *Evidence Requested* and *Uploaded* tabs support editing and status actions. For managing these items, see Manage Evidences. *** ### How to search for evidences 1. Go to **Audits > Evidences**. 2. Select the relevant tab (e.g. *Uploaded*, *Policy*, *Workflow*). 3. Use the **search bar** in the top-right corner to enter: * Evidence name * Identifier (e.g. EVD-001) * Keywords from custom metadata > 💡 The search bar supports partial matches and updates results as you type. *** ### How to filter evidences 1. Select the **Filter** button at the top of the table. 2. Choose the filters available for your current tab. *** #### Filter options by tab **Automated, Workflow, Uploaded, and Policy tabs:** * **Area**: Filter by evidence type such as Access, Trainings, Devices, Vendors, etc. * **Requested form**: Filter by submission source like Policy, Security, HR. * **Status**: Choose from Pending, Approved, or Rejected. * **Review pending by**: Filter evidences awaiting review by a specific user. **Evidence Requested tab:** * **Requested from**: Filter by the user the request was sent to. * **Review pending by**: Filter by the assigned reviewer. * **Request status**: Choose from: * Upload pending * Review pending * Re-upload pending * Uploaded 3. After applying the filters, the list will refresh to show matching results. 4. To remove filters, click **Clear all** or deselect individual filter values. *** ### Tips for effective searching * Use consistent naming conventions in evidence titles. * Apply multiple filters together to narrow your search (e.g. Area + Status). * Use identifiers (e.g. *EVD-024*) when searching for specific items. # Frequently Asked Questions (FAQs) Find answers to common questions about uploading, managing, and reviewing evidences in Sprinto's compliance dashboard. This article answers common questions about managing evidences in Sprinto, including uploading, requesting, editing, reviewing, and archiving. *** #### 1. What types of evidences are supported in Sprinto? Sprinto supports five types of evidences: * **Automated** – Collected via platform integrations and system checks. * **Workflow** – Captured from third-party workflow checks. * **Evidence Requested** – Uploaded by users in response to manual requests. * **Uploaded** – Manually added files or links. * **Policy** – Generated when a policy is created or approved within Sprinto. *** #### 2. Can I upload multiple evidences at once? Yes. Use the **Upload evidence** option under the **Uploaded** tab to upload multiple files or links. After uploading, you can assign metadata such as evidence group, collection date, and custom fields before saving. *** #### 3. What metadata can I add to evidence? You can assign the following metadata: * Evidence name * Evidence collected date * Evidence group * Associated controls * Auto-generated identifier (e.g. *EVD-001*) * Custom fields (e.g. department, document type, expiry date) *** #### 4. Can I edit evidence after uploading it? Yes, but only for evidences under the **Uploaded** and **Evidence Requested** tabs. You can update the evidence file, associated controls, metadata, or collected date. *** #### 5. How does version history work? Each time you update an evidence file, Sprinto creates a new version and retains the old one. You can view all versions from the **View evidence history** section in the evidence drawer. > 🛈 You cannot revert to previous versions, but they remain visible for reference. *** #### 6. Can I request evidence from other users? Yes. Use the **Request evidence** button to create a single or bulk evidence request. You can assign a recipient, set a due date, and optionally require a review. *** #### 7. What happens when I archive evidence? Archived evidences: * Remain linked to controls * Are hidden from audit workflows * Cannot be edited or updated * Are viewable under the **Archived** view within the Uploaded or Evidence Requested tabs *** #### 8. Can I search and filter evidences? Yes. You can search by evidence name or identifier and apply filters by Area, Form, Status, Reviewer, or Custom Field values. See [Search Evidences](https://chatgpt.com/g/g-p-682c1aeced3481919aef33cebb2d490f-sprinto-documentation-overhaul/c/684828cf-7700-8006-9de8-45f1017ddcee#) for details. *** #### 9. Can I attach evidence to audit requirements? Yes. During audit preparation, you can attach one or more evidences to a specific checklist item. Use the **Attach evidence** option within an audit event. *** #### 10. What’s the difference between Automated and Uploaded evidence? * **Automated evidence** is system-generated and cannot be modified. * **Uploaded evidence** is added manually and fully editable. # Glossary Understand key terms related to evidence management in Sprinto with this comprehensive glossary for audit and compliance workflows. This glossary defines key terms used across the **Evidences** section in Sprinto to help you better understand terminology related to uploading, reviewing, and managing audit artefacts.
TermDefinition
EvidenceA file or link that proves a security control or audit requirement has been met. It can be collected automatically, uploaded manually, or generated through workflows or policies.
Automated EvidenceEvidence collected by Sprinto’s system via integrations and monitoring. It is read-only and cannot be edited.
Workflow EvidenceEvidence generated through checks run on connected platforms like AWS, Google Workspace, or GitHub. This type is also read-only.
Evidence RequestedEvidence submitted by users in response to a request created through the Sprinto dashboard. It can be uploaded, reviewed, and archived.
Uploaded EvidenceManually added evidence files or links. This is the most flexible evidence type and supports metadata, control mapping, version history, and archiving.
Policy EvidenceEvidence automatically generated when a policy is uploaded, approved, or published in Sprinto. It is read-only.
Evidence GroupA label or category used to logically group related evidences (e.g. by audit event, department, or framework).
Evidence IdentifierA unique, auto-generated code (e.g. EVD-001) assigned to each uploaded evidence file.
Evidence Collected DateThe date the evidence was originally generated or obtained. This can be edited manually.
Custom FieldsUser-defined metadata fields (e.g. Department, Expiry Date, Type) that help organise and filter evidences.
Version HistoryA log of all updates made to a given evidence item, showing previous versions and timestamps.
Review RequiredA setting that, when enabled, allows a reviewer to approve or request changes to an evidence file.
Archived EvidenceEvidence that has been removed from audit visibility but remains linked to controls. It cannot be edited or updated.
Associated ControlsThe specific security or compliance controls that an evidence item is mapped to.
Audit RequirementA specific checklist item in an audit that requires proof of compliance, often fulfilled by attaching evidence.
# Overview Manage, approve, and track compliance policies across your organisation with Sprinto’s centralised Policies module. Sprinto helps you set up policies that are aligned with your compliance frameworks, track their approval and acknowledgment status, and ensure that your employees are always aware of the rules that govern your operations. *** ### **What are Policies?** Policies are documented rules that define how your organisation operates securely, ethically, and in compliance with regulatory requirements. They are essential for building trust with auditors, customers, and employees. Each policy sets the **what**—the rule itself—while procedures define the **how**—the steps required to implement or comply with the rule. Sprinto also supports non-policy artefacts, such as ISMS scope documents or audit reports, which can be submitted as evidence.
*** ### **Why use Policies in Sprinto?** * Get pre-configured policies tailored to your selected framework * Create or upload policies and procedures with flexible options * Assign approval workflows and track employee acknowledgements * Map policies to relevant security controls for audit readiness * Sync with Confluence or SharePoint to import existing documentation *** ### **Supported document types**
TypeDescription
PolicyDefines an organisational rule (e.g. All staff devices must be encrypted).
ProcedureDescribes how to implement a policy (e.g. Steps to enable encryption on Windows).
DocumentAny supporting artefact, such as an audit charter, vendor risk assessment, or system description.
You can create these using Sprinto templates, write them from scratch, upload them as PDFs, or sync them from Confluence or SharePoint. *** ### **Who is it for?**
RoleResponsibilities
Admins and InfoSec ownersSet up and maintain policies, assign reviewers, track acknowledgements, and monitor version history.
EmployeesView and acknowledge assigned policies through the employee portal.
AuditorsReview policy documents and control mappings during compliance assessments.
*** ### **Use cases**
ScenarioDescription
Initial setupCreate policies using framework-aligned templates to get started quickly.
Policy maintenanceKeep policies up to date, versioned, and reviewed by the right stakeholders.
Audit readinessMap policies to controls and generate evidence reports for audit cycles.
Organisation-wide rolloutAssign policies to specific teams or business units using zones.
Documentation syncAutomatically pull policies and procedures from Confluence or SharePoint.
# How it Works Learn how policies are created, approved, mapped, and maintained in Sprinto to support continuous compliance. The Policies module enables you to create, manage, and maintain documentation aligned with your compliance frameworks. Whether you use Sprinto templates, upload custom documents, or sync from Confluence, all policies follow a structured lifecycle designed to ensure audit readiness and team-wide visibility. *** ### **Step 1: Add a policy, procedure, or document** You can create a new item in the Policies module in one of the following ways:
MethodDescription
Use a Sprinto templateSelect from pre-built policies aligned with frameworks like ISO 27001, SOC 2, and GDPR.
Use the built-in editorDraft policies or procedures from scratch using Sprinto’s rich text editor.
Upload a fileUpload a non-editable document in PDF format.
Select from libraryChoose framework-required documents (e.g. ISMS scope) from Sprinto’s content library.
Sync from Confluence or SharePointImport policies directly using document labels and metadata.
Once added, each policy appears in **Draft** status and must be reviewed before it becomes active. *** ### **Step 2: Review and approve the policy** After drafting or uploading a policy: 1. Assign an **Approver** to the document. 2. (Optional) Assign **Reviewers**, who can comment but cannot approve. 3. Click **Send for approval**. Once the policy is approved, it moves from **Pending approval** to **Active**. Only active policies can be shared with employees for acknowledgement. *** ### **Step 3: Map security controls** For each approved policy, you can map it to specific controls required by your framework. * Use **AI-assisted mapping** to generate control suggestions. * Or manually select controls from the control drawer. * Once mapped, the policy acts as evidence for the selected controls. Policies created from templates often come with predefined control mappings. *** ### **Step 4: Monitor policy status and history** Every policy includes version history and metadata: * Track changes, approvals, and reviewer comments across versions. * View the status of each policy (Draft, Pending, Active, or Disabled). * Download documents or update branding from the three-dot menu. You can also use the **Monitoring tab** to set up compliance checks tied to policy acknowledgements, reviews, or evidence submissions. # Dashboard Actions Manage, review, and monitor all your policy actions in one place with Sprinto’s centralised dashboard tools. Perform key actions to create, manage, review, and monitor your organisation’s policies from a single unified dashboard. The **Dashboard Actions** section in the Policies module brings together all the tools required to keep your documentation up to date, review-ready, and audit-compliant. Whether you’re drafting a new policy, mapping controls, sending acknowledgement requests, or setting up recurring checks, this is where all operational actions begin. *** ### **What you can do from the dashboard**
ActionDescription
CreateAdd new policies, procedures, and documents using templates, built-in editors, uploads, or syncs from Confluence or SharePoint.
ManageEdit, version, disable, and review the lifecycle of existing documents. Assign reviewers and track version history.
ReviewEnable collaborative comments and feedback using the reviewer workflow. Approvers can finalise and publish documents.
MapLink documents to compliance controls for audit evidence and framework alignment. Use manual or AI-assisted mapping.
AcknowledgeSend requests for staff acknowledgement and track completion across teams. Supports onboarding and periodic use cases.
MonitorSet up recurring checks tied to policy tasks and track their health over time using the Monitoring tab.
*** ### **When to use dashboard actions** Use these actions during: * Initial framework setup and policy rollout * Quarterly or annual policy reviews * Staff onboarding and compliance training * Pre-audit evidence preparation # Create Policies and Documents Learn how to create and upload policies, procedures, and supporting documents in Sprinto. Sprinto provides multiple ways to create and manage your organisation’s documentation. You can generate policies using prebuilt templates, draft them manually, upload files, or import documents from your existing repositories like Confluence or SharePoint. All policies are created from the **All policies & docs** tab in the Policies module. *** ### **Before you begin** Ensure that: * You have the required role (Administrator or InfoSec Owner) to create documents. * At least one compliance framework is enabled in your Sprinto account to access the document library and framework-specific templates. *** ### **Ways to create or upload documents** You can create documents in Sprinto using any of the following methods. *** #### **1. Write from scratch using the built-in editor** 1. Log in to the Sprinto Dashboard and navigate to **Policies**.
2. Click **Add documents** > **Policies or procedures**.
3. Choose **Use a built-in policy editor** or **Use a built-in procedure editor**. 4. In the editor, enter a **Name of the document**. 5. Draft your content using the rich text formatting toolbar. 6. Assign an approver. 7. Click **Add document**.
{% hint style="info" %} This option is ideal for creating custom policies that do not follow a predefined template. {% endhint %} *** #### **2. Upload a non-editable document (PDF)** 1. Click **Add documents** > **Policies or procedures**. 2. Choose **Upload a non-editable document**.
1. Select the PDF file from your computer. 2. Enter the document name and assign an approver. 3. Click **Add document**.
{% hint style="info" %} Uploaded PDFs cannot be edited in Sprinto. To make changes, you must re-upload the file. {% endhint %} *** #### **3. Select from library** If your account has an enabled framework that supports document templates, you can select from Sprinto’s internal library. 1. Click **Add documents** > **Other documents**. 2. If visible, click **Select from library**.
3. Tick one or more documents from the list (e.g. *PCI Charter*, *ISMS Roles & Responsibilities and so on*). 4. Click **Add document**.
{% hint style="info" %} This option is only enabled if you have a framework that requires or supports the selected documents. {% endhint %} *** #### **4. Add a custom document** To add other types of compliance-related documents: 1. Click **Add documents** > **Other documents**. 2. Choose **Add a custom document**.
3. Select one of the following options: * **Upload file** (.pdf, .xlsx, .docx, .csv) * **Write on Sprinto** (opens the rich text editor) 4. Enter the document name and assign an approver. 5. Click **Add document**. *** #### **5. Sync from Confluence or SharePoint** If your policies are maintained in Confluence or SharePoint: 1. Click **Add documents**. 2. Under the **Sync** section, choose either: 1. **Sync from Confluence** 1. Select **I have the credentials** check box. 2. Click **Connect Confluence**.
3. Enter your **Confluence domain**, **Username** and **API token**. 4. Click **Connect Confluence**.
2. **Sync from SharePoint** 1. Select the **I have admin access to my Sharepoint account** check box. 2. Click **Connect to Sharepoint**.
3. In the pop-up that appears, select the OAuth option of your preference. 4. Enter your credentials and click **Connect**. 3. Ensure your documents are labelled correctly (e.g. `sprinto-policies`, `sprinto-procedures`). {% hint style="info" %} Synced documents are imported as non-editable PDFs and appear in **Draft** status. {% endhint %} *** ### **Next steps** After creating a policy or document: * It appears under the **Draft** section. * You can edit it, assign reviewers, and send it for approval. * Once approved, it becomes **Active** and can be acknowledged by employees. # Manage Policies and Versions Review, approve, edit, and track your policies and documents throughout their lifecycle. Understand how to manage policies throughout their lifecycle in Sprinto—from creation and approval to versioning, disabling, and re-enabling. *** ### Policy lifecycle The table below summarises the states a policy goes through and the available actions at each stage:
StatusDescriptionAvailable Actions
DraftPolicy is being written or revised.Edit content, assign reviewer, send for approval, delete, disable
Pending ApprovalPolicy has been submitted for approval by an assigned reviewer.Reviewer can approve or reject
ActivePolicy is live and accessible to users.Create new version, view details, disable
DisabledPolicy is no longer in effect.Enable policy (returns to Draft), view details
*** ### Video Guide Here's a short video on how to update policies. {% embed url="" %} ### Update reviewer You can change the approver of a policy document before it is sent for approval. #### Steps 1. Log in to the Sprinto Dashboard. 2. Go to the **Policies** section and click on a policy in Draft status you wish to update. 3. In the **Details** panel on the right, click **Edit**.
4. In the **Approver** field, select a new reviewer from the list of available roles. 5. Click **Save**.
*** ### Send a policy for approval Once your policy draft is finalised, send it for approval to activate it. Here's a short video explaining the same. {% embed url="" %} #### Steps 1. Open the policy in **Draft** status. 2. Click **Send for approval**.
3. In the **Document preview** step, review the content. 4. Click **Next**.
5. Enter a version number and optional notes. 6. Click **Send for approval** to complete the submission.
The approver must approve this version for it to become Active. *** Add the following section under **Manage Policies and Versions**. *** ### Mark a Policy as Approved If a policy was reviewed and approved outside Sprinto, you can manually record the approval within Sprinto. This helps maintain an accurate approval history and compliance record without requiring the approval workflow to be completed in the platform. {% hint style="info" %} #### Note This is an on-demand feature. Contact Sprinto Support to enable it for your organisation. {% endhint %} #### Mark a policy as approved 1. From the Sprinto dashboard, go to **Policies**.
2. Select the policy or document that was approved outside Sprinto. 3. In the policy details panel, under **Status**, click **View details**.
4. In the **Approval path** section, click **mark it as approved**.
5. In the **Mark document as approved** window: 1. Select the **Approved on** date. 2. Select one or more **Approvers**. 3. (Optional) Add approval notes. 4. (Optional) Upload supporting evidence, such as signed documents or approval records. 6. Click **Mark as approved**.
The policy status changes to **Approved**, and the approval details are recorded against the active version of the document. #### Edit approval details After a policy has been marked as approved, you can update the approval information if required. 1. Open the policy from the **Policies** page. 2. In the policy details panel, locate the **Status** section. 3. Click **Edit** next to the approval status.
4. Update any of the following information: * Approval date * Approvers * Notes * Supporting evidence 5. Click **Save changes**.
The updated approval details are saved and reflected in the policy record. #### What information can you record? When manually approving a policy, you can capture:
FieldDescription
Approved onThe date on which the policy was approved outside Sprinto.
ApproversOne or more individuals who approved the policy.
NotesAdditional context or comments related to the approval.
EvidenceSupporting documents that validate the approval, such as signed copies, emails, or approval records.
#### Use cases You can use manual approval when: * Policy approvals are managed through an external governance or legal process. * Approval evidence exists outside Sprinto. * Historical policy approvals need to be recorded for audit purposes. * A policy was approved before Sprinto was implemented and needs to be brought into compliance records. {% hint style="warning" %} #### Important Manually marking a policy as approved records the approval outcome in Sprinto. Ensure that the approval date, approvers, and supporting evidence accurately reflect the external approval process. {% endhint %} *** ### Create a new version To make updates to an Active policy, create a new version. #### Steps 1. Click the policy with **Active** status. 2. Click **+ New version**.
3. Click Other options to add a new version if you wish to **Revert template to default content** or **Upload file.** 4. Select one of the following options: * **Revert template to default content**: Load the default Sprinto template and edit it. * **Upload file**: Add a PDF version of the policy (non-editable).
5. Edit the draft and click **Save as draft**.
6. Send the new version for approval following the same steps as above. *** ### Disable or re-enable a policy If a policy is no longer applicable, you can disable it. Re-enabling requires re-approval. #### Disable a policy 1. Scroll to the bottom of the Active policy view. 2. Click **Disable document**.
3. The policy is moved to **Disabled** state. #### Re-enable a policy 1. Open the disabled policy. 2. Click **Enable**.
3. The document returns to Draft status. 4. Send the policy for approval again to make it Active. *** ### View policy history Track all policy versions and their status. #### Steps 1. Open the policy. 2. Scroll down to **Document versions**.
3. View all previous versions (e.g. v1, v2) along with their status. 4. Click **Details** beside any version to see: * Version number * Created by * Disabled by (If the Policy is disabled) * Creation date * Type (Template-based or PDF upload)
### Set up a System Description Here's a short video that explains how to set up a system description for SOC2 compliance. {% embed url="" %} # Review Policies with Comments Enable collaborative policy review with in-line comments before a document is approved. Sprinto supports a dedicated **Reviewer** role to help teams collaboratively review policy and procedure drafts. Reviewers can leave comments, suggest changes, and highlight content—without editing the document or affecting its approval state. All comments are visible only during the **Draft** stage. *** ### **Who can review a policy?**
RolePermissions
ReviewerCan comment on a draft, highlight content, and tag suggestions. Cannot edit or approve the policy.
ApproverCan view reviewer comments and approve the document.
AuthorCan view, reply to, and resolve comments. Can send the document for approval.
{% hint style="info" %} You can assign multiple reviewers to a single document, but only one approver. {% endhint %} *** ### **Add comments to a document** 1. Open the policy as a reviewer. 2. Highlight any portion of the content in the left pane. 3. Click **Add comment** in the right pane. 4. Type your comment and click **Save**. You can: * Edit or delete your own comments * Reply to others' comments (if you're the author or reviewer) * View all unresolved comments in the right-hand comment thread *** ### **Resolve comments** Authors or approvers can resolve comments during the review process. * To resolve a comment, click the three-dot menu next to the comment and select **Delete**. * All unresolved comments are automatically removed once the policy is approved. {% hint style="info" %} Due to editor limitations, resolving a comment currently deletes it. Comments are stored as in-line tags using TinyMCE spans and conversation IDs. {% endhint %} *** ### **What happens after approval?** Once the approver clicks **Approve**: * The document status changes to **Active** * All comments are cleared from the draft * The reviewer thread is no longer accessible This ensures that approved policies remain clean and finalised for staff and audits. *** ### **Best practices** * Use comments to suggest changes without altering the policy directly. * Review all feedback before sending a policy for approval. * Let reviewers know when their feedback has been addressed. *** ### **Next steps** Once the review is complete: * Approvers can approve the policy and move it to **Active** * The policy can then be acknowledged by employees * You can version the policy later if further changes are required. # Map Security Controls to Policies Link your policies to relevant controls to support evidence collection and compliance reporting. Sprinto allows you to map each policy, procedure, or document to one or more security controls. Control mapping is essential for frameworks such as ISO 27001, SOC 2, and GDPR, where written documentation must directly support control implementation. You can map controls manually or use Sprinto’s AI-assisted suggestions. *** ### **Before you begin** * Ensure the policy or document is in **Draft** or **Active** status. * Make sure you have the required role (Administrator or InfoSec Owner) to modify control mappings. * Note that pre-mapped policies generated from Sprinto templates cannot be edited. *** ### **Ways to map controls**
MethodDescription
Manual mappingSelect controls directly from the available control categories.
AI-assisted mappingUse Sprinto AI to generate control suggestions based on policy content.
*** ### **Manually map controls to a Policy** Here's a short video on how to map controls to a policy. {% embed url="" %} 1. Navigate to the **All policies & docs** tab. 2. Click on the policy or document you want to map. 3. In the **Controls mapped to policy** section, click **Map controls.**
4. Use the search bar or browse categories to select relevant controls. You can also click **Generate** **suggestions** to get AI assistance in mapping controls. 5. Click **Save mapping** after you select the controls you wish to map to your policy**.**
{% hint style="info" %} Mapped controls are listed in the policy details view. These mappings are also visible during audits and evidence exports. {% endhint %} *** ### **Use AI-assisted control mapping** 1. Open the desired policy. 2. In the **Controls mapped to policy** section, click **Map controls**. 3. From the left-hand panel, select **Sprinto AI**. 4. Click **Generate suggestions**.
5. Review the AI-suggested controls (identified by a Sprinto-AI icon). 6. Select the controls you want to map. 7. Click **Save mapping**. {% hint style="info" %} If needed, you can override AI suggestions by adding additional controls manually. {% endhint %} *** ### **View mapped controls** Once saved: * All mapped controls are visible in the **Controls mapped to policy** section. * Mapped policies serve as evidence for those controls during audits. * Reviewers and approvers can see the mappings during the policy approval workflow. *** ### **Limitations** * **Template-generated policies** come with predefined control mappings that cannot be modified. * **Uploaded PDFs or synced documents** must first be approved before controls can be mapped. * Controls can only be mapped if they exist in the active framework enabled for your organisation. *** ### **Next steps** Once controls are mapped: * The policy contributes to the “Document should be mapped” check. * The policy is available as evidence in control drawers during audit preparation. * You can monitor the mapping status from the **Monitoring** tab. # Manage Policy Branding and Downloads Apply your organisation’s branding to all policies and download documents for sharing, record-keeping, or audit submission. Sprinto allows you to customise the branding of your policy documents and download them in bulk or individually. You can choose to use your default company branding or apply a custom display name and logo. Draft and active documents can be exported as needed. *** ### **Apply or update policy branding** Here's a short video on how to manage your branding. {% embed url="" %} 1. Go to the **All policies & docs** tab. 2. Click the **three-dot menu** (⋯) at the top left. 3. Select **Manage branding**.
4. Choose one of the following options: * Use default display name and logo from Profile (as set in Company Profile) * Use other display name and logo (manually enter display name and upload logo) 5. Click **Save**.
{% hint style="info" %} Your branding will appear on the cover page of all generated policies and procedures, including those exported for audits or employee use. {% endhint %} *** ### **Download policy documents** You can download individual policies or bulk export multiple documents. #### Download a single policy 1. Click on the policy card you want to export. 2. In the policy view, click the **Download** icon.
#### Download multiple policies 1. Go to the **All policies & docs** tab. 2. Click the **three-dot menu** (⋯). 3. Select **Download**.
4. In the drawer, choose: * Whether to **include draft policies** * Specific documents to include in the download 5. Click **Download \[X] documents**.
{% hint style="info" %} Draft documents are excluded by default unless selected explicitly. {% endhint %} *** ### **Best practices** * Use **default branding** to maintain consistency across all system-generated documents. * Download all **active policies** before an audit to provide a consistent document set to auditors. * Apply **custom branding** if you are a service provider or if the policies are shared externally. *** ### **Next steps** After branding and exporting your policies, you can: * Use them in evidence packages for audit submissions. * Review version history and change logs. * Monitor associated policy checks in the Monitoring tab. # Policy Registers Create, manage, archive, and track policy registers in Sprinto to organise policies by zones, send acknowledgement requests, and monitor completion status. Policy Registers help you group policies and procedures into structured collections that apply to specific zones within your organisation. Registers make it easier to manage policies at scale by allowing you to: * Organise policies into logical groups. * Map policy collections to one or more zones. * Request periodic acknowledgement from staff. * Track acknowledgement completion across recipients. * Maintain visibility into the policies included in each register. Each policy register acts as a reusable policy collection that can be scoped to different areas of your organisation. *** ## How Policy Registers work A policy register contains: * A register name. * One or more mapped zones. * Selected policies and procedures. * Acknowledgement workflows. * Acknowledgement status tracking. Once a register is created: 1. Policies included in the register become associated with the mapped zones. 2. Policy acknowledgement requests can be sent to staff. 3. Completion progress can be tracked from a single location. 4. Register-level updates remain visible across policy workflows. {% hint style="info" %} #### Note Changes made to policies inside a register are reflected globally. Policy modifications are not register-scoped. {% endhint %} *** ## Create a policy register Create a policy register to organise policies by zone and acknowledgement workflow. ### Before you begin Make sure that: * Policies and procedures already exist in Sprinto. * Zones are configured. * You know which policies must belong to the register. ### Create a register 1. Log in to the Sprinto dashboard. 2. Go to **Policies**. 3. Select the **Policy registers** tab. 4. Click **Create register**.
5. In the drawer, enter a **Register name**. 6. Under **Map to zones**, select one or more zones. 7. Under **Select policies**, choose policies to include. 8. Click **Create register**.
The register appears in the Policy Registers dashboard. ### Select policies You can add policies using either of the following methods: #### Select all policies Use **Select all** to add every available policy to the register. #### Select specific policies Select only the policies you want to include. You can: * Search for policies. * Select individual policies. * Remove selected policies before saving. {% hint style="info" %} #### Note The zone field supports multiple selections. A single register can apply to multiple zones. {% endhint %} *** ## View a policy register Open a policy register to view included policies, status information, and acknowledgement workflows. ### Open a register 1. Go to **Policies** > **Policy registers**. 2. Click a register name.
Inside the register, Sprinto displays: * Policies and procedures included in the register. * Policy type. * Version status. * Activity status. * Author information. * Approver details. * Reviewer assignments.
### Available tabs Each register contains the following tabs:
TabDescription
Policies & ScopeDisplays all policies included in the register.
Policy AcknowledgementAllows acknowledgement requests to be created and managed.
Acknowledgement StatusDisplays recipient-level acknowledgement tracking.
*** ## Manage policies inside a register The **Policies & Scope** tab gives visibility into all policies included in the register. ### Available actions You can: * Filter by document type. * Filter by latest version status. * Search for policies. * Duplicate the current table view. * Sort policy data. * Review approval ownership. ### Policy visibility Each row shows:
FieldDescription
NamePolicy or procedure name.
TypePolicy or Procedure.
StatusCurrent lifecycle status.
ActivityActivity indicator for the document.
AuthorPolicy owner or creator.
ApproverAssigned approver.
ReviewersAssigned reviewers.
{% hint style="info" %} #### Note Changes made to policies in a register affect the same policy globally across Sprinto. {% endhint %} *** ## Edit a policy register Update a register when policies, zones, or naming conventions change. ### Edit register details 1. Open a policy register. 2. Click **Edit details**.
3. Update any of the following: * Register name * Zone mapping * Included policies 4. Click **Save changes**.
The updated configuration is immediately reflected inside the register. ### Update zones The zone selector is a multi-select field. You can: * Add new zones. * Remove existing zones. * Map a register to multiple zones. ### Update policies You can: * Add additional policies. * Remove policies. * Use search to locate policies. * Select or deselect policies individually. *** ## Archive a policy register Archive a register when it is no longer required. ### Archive a register 1. Open a policy register. 2. Click **Archive register**.
3. Review the confirmation message. 4. Click **Archive register** again.
The register status changes to **Archived**. Archived registers remain visible in the dashboard. ### Archive behaviour When a register is archived: * Policies become unlinked from the register. * Zone mapping is removed. * Associated monitors stop running. * Register workflows become inactive. {% hint style="warning" %} #### Important Archiving a policy register deactivates monitors associated with the register. {% endhint %} *** ## Unarchive a policy register Restore a previously archived register when needed. ### Unarchive a register 1. Open an archived policy register. 2. Click **Unarchive register**.
Sprinto restores: * Policies associated with the register. * Zone mappings. * Monitor relationships. *** ## Policy acknowledgement Use policy acknowledgement requests to confirm that staff have reviewed policies contained within a register. ### Policy acknowledgement overview The **Policy Acknowledgement** tab allows administrators to: * Create acknowledgement requests. * Notify staff. * Limit acknowledgement to selected staff. * Track progress. * Review acknowledgement history. The page also displays: * Upcoming acknowledgement-related tasks. * Due reminders. * Next acknowledgement cycle. *** ## Create a policy acknowledgement request ### Create a request 1. Open a policy register. 2. Go to the **Policy Acknowledgement** tab. 3. Click **Create new request**.
4. Enter a **Policy acknowledgement name**. 5. Review the included policies and procedures.
The request is added to the acknowledgement table. *** ## Notify staff about acknowledgement requests You can send email notifications alongside acknowledgement requests. ### Send notifications 1. Enable **Notify staff about this acknowledgement request**. 2. Configure: * Mail subject * Mail content 3. Review the email content. 4. Continue creating the request.
### Email placeholders Email content supports dynamic values. For example: * `{{staff_name}}` Sprinto replaces placeholders with recipient-specific values. *** ## Review included policies The acknowledgement request drawer displays all policies included in the request. Each row displays:
ColumnDescription
Document namePolicy or procedure title.
VersionCurrent policy version.
Applicable forNumber of staff who must acknowledge the policy.
*** ## Send acknowledgement to specific staff By default, acknowledgement applies to all eligible staff. You can instead limit the request to selected recipients. ### Select specific staff 1. Click **Select staff**.
2. Search for staff members. 3. Select one or more recipients. 4. Click **Save**.
Sprinto displays the number of selected staff. ### Edit selected recipients After selecting staff: 1. Click **Edit** to update recipients.
2. Add or remove staff from the selected list. 3. Click **Save** to save changes.
### Reset to default audience Click **Reset to default** to restore acknowledgement to all eligible staff.
*** ## Employee-group applicability Policy acknowledgement can be customised using employee groups. This depends on policy-level applicability settings. ### Configure employee-group applicability 1. Open a policy. 2. Go to policy details. 3. Locate the **Applicable to** section. 4. Select employee groups. Employee groups are sourced from your identity provider. Click **Request acknowledgement** to send your Policy acknowledgement. *** ## View acknowledgement requests The acknowledgement request table displays created requests. ### Available columns
ColumnDescription
Acknowledgement request nameRequest identifier.
Requested onDate the request was created.
Policies & ProceduresNumber of included policies.
ProgressCompletion percentage.
ActionsAvailable request actions.
### Available actions You can: * View included policies. * Open acknowledgement details. * Track progress. *** ## Track acknowledgement status The **Acknowledgement Status** tab provides recipient-level tracking. This helps administrators monitor who has acknowledged policies. ### Open acknowledgement status 1. Open a policy register. 2. Go to **Acknowledgement Status**.
### Available columns
ColumnDescription
Acknowledgement nameName of the acknowledgement request.
RegisterPolicy register name.
PersonRecipient.
Requested onDate acknowledgement was requested.
Acknowledged onDate acknowledgement was completed.
ChecksCurrent acknowledgement state.
### Status indicators Acknowledgement status may display:
StatusDescription
DueAwaiting acknowledgement.
CompletedPolicy acknowledgement finished.
PendingRequest exists but action is incomplete.
*** ## Policy lifecycle within registers The following lifecycle explains how policy registers move through configuration and acknowledgement workflows.
StageDescription
Create registerCreate a register and map policies to zones.
Configure scopeAdd or remove policies and update zone mapping.
Send acknowledgementCreate acknowledgement requests for staff.
Track acknowledgementMonitor completion progress and recipient status.
ArchiveDeactivate the register and associated workflows.
UnarchiveRestore the register and resume workflows.
# Track Policy Status and History Track policy versions, approvals, and control mappings in Sprinto to ensure continuous compliance and audit readiness. Sprinto provides full transparency into the lifecycle of your policies. You can track document versions, approval status, system check results, and control mappings—all in one place. This helps ensure that your organisation stays compliant with evolving frameworks and audit expectations. *** ### **Check the current status of a policy** Each policy in Sprinto exists in one of the following states:
StatusDescription
DraftThe policy has been created but not yet submitted for approval.
Pending approvalThe policy has been sent for approval but is not yet active.
ActiveThe policy has been approved and is accessible to employees.
DisabledThe policy has been deactivated and is hidden from employee view.
To view a policy's current status: 1. Navigate to the **All policies & docs** tab. 2. Open the document card. 3. The current status is shown at the top of the details panel (e.g. *Active: v4.1.1, Draft: v4.1.2*).
*** ### **Track policy-related system checks** Sprinto automatically monitors compliance status using built-in checks linked to policies. These checks include:
Check nameDescription
Document should be set upEnsures that required documents are created and approved.
Controls should be mappedEnsures that a policy is mapped to relevant framework controls.
Policy should be acknowledgedTracks employee acknowledgements for active policies.
To view check results: 1. Click the **three-dot menu** (⋯) from the top left of the All policies & docs tab. 2. Select **Status history**. 3. Use filters to review specific checks, frameworks, or time periods.
*** ### **Review control mappings** 1. Open any active or draft policy. 2. In the **Controls mapped to policy** section, click **Edit**.
3. Review which controls are mapped and which frameworks they relate to. Mapped controls act as evidence during audit preparation and are visible in control drawers. *** ### **Download policy history** 1. Open the **Status history** view from the three-dot menu (⋯). 2. Use filters to narrow your view. 3. Click **Download evidence** to export the check history and control mapping status.
*** ### **Next steps** Once you’ve reviewed policy status and version history, you can: * Create a new version * Update control mappings * Reassign reviewers or approvers * Use the Monitoring tab to track compliance across teams # Send a Policy Acknowledgement Request Request employees to review and acknowledge policies as part of onboarding or periodic compliance. In Sprinto, acknowledgement requests allow you to ensure that staff are aware of key policies and procedures. You can send acknowledgements on demand, or configure them to trigger automatically when new employees are onboarded. All responses are recorded and tracked in the Acknowledgement Status tab. *** ### **Before you begin** * Make sure the policy or procedure has been approved and is in **Active** status. * Ensure employees are already added to Sprinto with valid email addresses. * Decide whether the request is **onboarding-linked** or **one-time**. *** ### **Send a new acknowledgement request** Here's a short video on how to Create an Acknowledgement request. {% embed url="" %} 1. Go to the **Acknowledgement Requests** tab. 2. Click **Create new request**.
3. Click **Edit** and select the policies and procedures you want acknowledged.
3. Click **Save**. 4. Click **Request acknowledgement**. {% hint style="info" %} Employees will receive an email or in-app notification with a link to the policy. Acknowledgement is recorded when they click **I acknowledge** in the Sprinto Employee Portal. {% endhint %} *** ### **Track acknowledgement progress** After sending a request: 1. Go to the **Acknowledgement Requests** tab. 2. View progress bars for each request. 3. Click **View details** to see: * Policies included * Staff assigned * Acknowledgement percentage * Due dates (if configured)
*** ### **Manage previous and upcoming requests** * Use the **“View previous requests”** option to review older campaigns. * Sprinto automatically schedules the **next periodic request** (e.g. 1 year after the last). * You can create a new request at any time—even before the next one is due. # Track Policy Acknowledgement Status Monitor which employees have acknowledged assigned policies, and identify those who are overdue or non-compliant. Sprinto’s **Acknowledgement Status** tab provides a detailed view of employee responses to acknowledgement requests. You can track completion across policies, teams, or individuals, and take action when staff miss critical deadlines. *** ### **View acknowledgement status** 1. Go to the **Acknowledgement Status** tab in the Policies module. 2. The table displays all users along with: * Name and email address * Acknowledgement summary (e.g. *All 3 Failing*, *20 Failing, 13 Passing*) * Status pills in red, amber, green, or blue
*** ### **Understand acknowledgement statuses**
StatusMeaning
Passing (Green)The employee has acknowledged all assigned policies within the required timeframe.
Due (Blue)The acknowledgement is pending but within the acceptable window.
Critical (Amber)The acknowledgement is overdue. A reminder may be needed.
Failing (Red)The employee failed to acknowledge one or more policies after the grace period.
{% hint style="info" %} Sprinto auto-updates status based on policy deadlines. These thresholds are configurable per framework. {% endhint %} *** ### **Filter by team or request** 1. Click the **Filter** button at the top right. 2. Apply filters based on: * **Acknowledgement request** * **Status** (Passing, Critical, Failing, etc.) 3. Click **Apply** to update the view.
Use filters to identify at-risk groups or narrow in on a specific request cycle. *** ### **Take action on failing or overdue acknowledgements** While viewing filtered results: * Trigger manual reminders using in-platform options (if enabled). * Investigate root causes of failure (e.g. team onboarding delays). * Reassign the acknowledgement if required. *** ### **Next steps** Once acknowledgement status is reviewed: * Update policies or resend requests if needed * Use Monitoring tab to verify if failed acknowledgements are affecting check status * Export acknowledgement logs during audits # View Acknowledgement History for an Employee View detailed acknowledgement history for each employee to track policy compliance and audit readiness over time. Sprinto lets you view a complete breakdown of acknowledgement responses for each staff member. This is useful for reviewing an employee’s compliance history over multiple policy campaigns or onboarding cycles. *** ### **Open the Acknowledgement Status tab** 1. Go to the **Acknowledgement Status** tab from the Policies module. 2. Locate the employee whose history you want to review. 3. Click anywhere on the row to expand the view.
*** ### **Understand the acknowledgement history view** The expanded row shows a table containing:
FieldDescription
Acknowledgement nameThe name of the request (e.g. Onboarding Staff Acknowledgement).
Requested onThe date the policy was sent to the employee.
Acknowledged onThe date the employee completed the acknowledgement (or blank if pending).
StatusShows if the employee is Passing, Failing, or Critical for that request.
{% hint style="info" %} Policies listed under a request are not shown individually here, but the overall result reflects the entire bundle. {% endhint %} *** ### **Use cases for acknowledgement history** * Confirm whether a user has acknowledged a specific request * Identify if the employee has repeatedly failed or delayed acknowledgements * Provide this record as evidence during internal audits or HR escalations *** ### **Best practices** * Review history before triggering reminders or assigning policy re-acknowledgement * Combine this view with filters for zone, request, or team * Use in conjunction with version history to track what the employee acknowledged *** ### **Next steps** If acknowledgement is missing or overdue: * Reassign the request via the **Acknowledgement Requests** tab * Contact the team owner for follow-up * Use this data to feed into periodic monitoring check. # Set Up Policy Monitoring Checks Set up recurring policy monitoring checks in Sprinto to ensure timely reviews, acknowledgements, and compliance tracking. Use policy checks in the Monitoring tab to track ongoing compliance, assign responsibilities, and ensure timely reviews and acknowledgements. Sprinto’s monitoring system allows you to define recurring checks related to your policies—such as “Ensure policy is acknowledged quarterly” or “Review encryption policy every 6 months”. These checks can be linked to policies, procedures, or compliance obligations. *** ### **Access the Monitoring tab** 1. Go to the **Monitoring** tab in the Policies module. 2. You’ll see an overview of: * Active checks * Passing checks * Failing or critical checks * Task-level status counts (e.g. Due, Critical, Failing)
*** ### **Add a monitoring check** 1. Click **Add checks**. 2. In the drawer, choose one of the following options: * **Add from template** – Use pre-configured checks mapped to compliance frameworks. * **Single workflow check** – Create a custom check manually. * **Bulk upload workflow checks** – Upload a spreadsheet containing multiple checks.
*** ### **Add from template** 1. Click **Add from template**. 2. In the left pane, select a category (e.g. People, Infrastructure, Privacy). 3. Review the suggested checks and their mapped frameworks.
4. Select one or more checks and select a zone in the **Zone Details** section. 5. Click **Add check**.
{% hint style="info" %} Templates include predefined frequency, task responsibility, and mapping logic. You can customise them after adding. {% endhint %} *** ### **Create a single workflow check** 1. Choose **Single workflow check**. 2. Fill in the following fields: * **Check name** and **description** * **Instruction for assignee** * **Start date** and **recurrence frequency** * **Zone** or team responsibility * **Assignee** and **review requirement** 3. Click **Create check**.
{% hint style="info" %} These checks appear in your Monitoring dashboard and are assigned as repeating tasks. {% endhint %} *** ### **Bulk upload workflow checks** 1. Click **Bulk upload workflow checks**. 2. Download the provided template (`.xlsx` format). 3. Fill in check details such as: * Name, description, frequency, zone, assigned owner * Optional: review requirement and start date 4. Upload the completed spreadsheet back to Sprinto. 5. Click **Next**.
{% hint style="info" %} Use this option when setting up dozens of checks during framework onboarding or internal rollout. {% endhint %} *** ### **Next steps** Once checks are added: * You can view their task status (Passing, Failing, Critical) * Click **View & fix** to update outcomes * Use the **Status history** option to export evidence for audits # Track Policy Check Outcomes Track policy check outcomes in Sprinto to identify compliance gaps, manage overdue tasks, and maintain audit readiness. Sprinto’s Monitoring tab provides visibility into every active check you’ve configured—whether manually created or template-based. Each check tracks its own outcomes over time and contributes to your audit readiness. *** ### **View check outcomes** 1. Go to the **Monitoring** tab in the Policies module. 2. Use the dashboard to view: * Total number of checks * Status summary (Passing, Critical, Failing, Due) * Volume of open tasks across all checks *** ### **Understand check status indicators**
StatusDescription
Passing (Green)All tasks related to this check have been completed on time.
Due (Blue)Tasks are currently pending but still within their due window.
Critical (Amber)The task is overdue and nearing the failure threshold.
Failing (Red)The task deadline has passed without completion or review.
{% hint style="info" %} Status is determined by the task start date, frequency, and whether review was required. {% endhint %} *** ### **Drill down into a specific check** 1. In the Monitoring dashboard, click **View & fix** or **View details** for any check. 2. This opens the detailed drawer with: * Description and instructions * Assigned owner or reviewer * Start date and recurrence frequency * Zones or teams responsible * Task history and current status *** ### **Download check history and evidence** 1. From the Monitoring tab, click the **three-dot menu**. 2. Select **Status history**. 3. Use filters to narrow down by: * Entity (e.g. OrgPolicyType) * Check name or type * Status (Passing, Failing, etc.) * Time period 4. Click **Download evidence** to export a CSV containing your selected check outcomes. *** ### **Best practices** * Assign checks to teams or zones to decentralise responsibility. * Use filters to quickly triage overdue or failing checks. * Review evidence logs periodically to ensure audit readiness. * Combine Monitoring data with Acknowledgement Status to identify risk areas. *** ### **Next steps** * If a check is failing, follow up with the assigned owner. * Review and update the check frequency or task instruction if needed. * Use this data to prepare control evidence before your next audit. # Policy Acknowledgement in Slack Allow staff to review and acknowledge Sprinto policies directly within Slack, without switching to the Employee Portal. Sprinto enables staff to acknowledge policies directly in Slack, eliminating the need to log into the Employee Portal for every task. Admins can trigger acknowledgement requests from the Policies module, and employees receive Slack notifications with full review and acknowledgement capabilities. This reduces delays, ensures faster compliance, and supports teams that primarily use Slack for daily communication. ### How it Works 1. Admins publish or trigger a policy acknowledgement request in the **Policies module**. 2. Staff members receive a **Slack direct message** listing pending policy acknowledgements. 3. Employees can: * Open a **modal** to review the policy title, description (auto-summarised or configured in Policies), and links. * Download the policy as a **PDF**. * View the policy in the Sprinto app (optional). * Navigate across policies with **Next/Back** buttons and see progress indicators (e.g. “1 of 3”). * Acknowledge individual or bulk policies directly in Slack. 4. Once acknowledged, the status is **synced automatically** with the Employee Portal. 5. If staff attempt to acknowledge again, they’ll see the message:\ *“You acknowledged this policy on DD/MM/YYYY”* with a link to the Sprinto app. ### Procedure Follow these steps to use Slack for policy acknowledgement: 1. **Set up Slack integration** * Navigate to **Settings > Notifications** in Sprinto. * Connect your Slack workspace and enable Slack as a notification channel. 2. **Admin triggers acknowledgement request** * Open the **Policies module**. * Select the policies and create an acknowledgement request. * Notify all relevant staff. 3. **Employee reviews policies in Slack** * Staff receive a **Slack DM** with acknowledgement tasks. * Click **Review Policy** to open the modal. * Review title, description, and download if needed. * Use **Next/Back** to navigate across policies. 4. **Acknowledge policies** * Tick the **Acknowledge** option after reviewing all policies. * Submit acknowledgement directly from Slack. * The Employee Portal status updates in real time. ### Use Cases
ScenarioBenefit
SMBs relying heavily on SlackEliminates delays from missed emails and improves completion rates
Employees with multiple policies pendingAllows quick bulk acknowledgement in Slack
Admins tracking policy complianceReal-time sync ensures acknowledgement is captured in Sprinto without extra steps
Staff on-the-goReview and acknowledge without logging into the Employee Portal
# Sync Policies & Documents from Confluence The following guide helps you in syncing the policies and procedures documents from the Confluence account. The feature helps especially in cases where you are already maintaining the organization's policies and other documents on Confluence and wish to publish them for staff through Sprinto’s employee portal, eliminating the policies set up on Sprinto. To sync documents, you need to integrate your Confluence account with Sprinto. Ensure you've added Sprinto's predefined labels to the documents; Sprinto syncs and categorizes the documents based on the labels tagged to them. #### Sprinto labels for document syncing Use the following labels to define the document type on Confluence:
Document TypeLabels
Policiessprinto-policies
Procedure documentssprinto-procedures
Other documentssprinto-docs
### Before you begin * Log in to Sprinto’s admin portal using your credentials. * Ensure you have integrated your Confluence account with Sprinto. Refer to our detailed integration guide on [integrating Confluence as a policy source](/integrations/overview/confluence-integration) for detailed instructions. ### Procedures Follow the below applicable procedure: #### Syncing documents from Confluence 1. Adding labels against documents on Confluence. * Log in to the[ Confluence account](https://www.atlassian.com/software/confluence) using your credentials. * Open a document in editing mode for which you wish to add a label. * Click on the three dots option from the top-right corner, and select Add labels.
* Add the label to define the document type. For more details about the available labels, refer to the Sprinto labels for the document syncing table at the top. * Once the label is added, click Close.
* Click Update to save the changes.
2. Syncing documents through Confluence. * Go to Policies and select **All** policies & docs tab. * Click Add document.
* Click Sync from confluence from the Add a policy or procedure document page.
* Review the synced documents. Click View document next to any document to review them. \ Note: As mentioned in Step 1, you can add labels to the Confluence documents and click Refresh to detect the required documents.
* Click Sync policies & docs to proceed further.\ **Note**: The synced documents are added under the "Draft Documents" category until sent and approved.
3. Setting up documents.\ If necessary, you can modify the following details about the document: * Select the document you want to update from the[ Policies & procedures](https://app.sprinto.com/app/admin/policies) tab.\ Note: You can find a Confluence logo for the synced documents.
* Click Edit from the Details section to modify the document’s identifier and policy owner. * Click Sync to sync the latest version of the policy/procedure. * Click Manage from the Applicable to section to change the default applicability. This feature works only when you have imported the employee groups through the identity or HRMS service integrations. * Click Edit from the Controls mapped to policy section to map the security controls against the selected policy.
#### Sending documents for approval Follow the procedure below to send the synced documents for approval: * Select a synced document for which you want to send for approval from the[ All Policies & docs](https://app.sprinto.com/app/admin/policies) tab. * Click Approve document to send the draft for approval. The assigned policy owner gets notified about pending approvals. Once the policy owner approves the document, it moves from the Draft to the Active stage and becomes available for the applicable staff members through Sprinto's employee portal. Alternatively, you can click **Send All** for approval to send all policies/procedures for approval in bulk.
#### Support Please get in touch with our [support team](mailto:www.support@sprinto.com) if you have any queries related to the document syncing or need assistance. # Frequently Asked Questions Get quick answers to common questions about creating, reviewing, and managing policies in Sprinto’s compliance platform. Find answers to common questions about creating, managing, and mapping policies in Sprinto. *** #### **1. What types of documents can I create in the Policies module?** Sprinto supports three types of documents: * **Policy** – Describes what rule or requirement must be followed. * **Procedure** – Explains how a policy is to be implemented. * **Document** – A general artefact such as an ISMS scope or audit charter. *** #### **2. Can I use templates to create policies?** Yes. Sprinto offers pre-filled templates that are mapped to your enabled frameworks (e.g. ISO 27001, SOC 2). You can customise these before sending them for approval. *** #### **3. Can I edit a policy after it becomes active?** No. Once a policy is active, it cannot be edited directly. You must create a **new version** to update the content. *** #### **4. What happens when I upload a PDF policy?** Uploaded policies are non-editable. They must be approved before they can be used. If changes are needed later, you must upload a new version of the file. *** #### **5. Can I assign multiple reviewers to a document?** Yes. You can assign multiple reviewers, who can leave comments and suggestions. However, only one **approver** can approve the document. *** #### **6. What is the difference between a reviewer and an approver?** * **Reviewer** – Can add and reply to comments on draft content, but cannot approve the document. * **Approver** – Has final approval rights and can send the document to active status. *** #### **7. Why is 'Select from library' not clickable?** The option is enabled only when: * Your organisation has an active compliance framework (e.g. PCI DSS or ISO 27001). * The selected framework supports document templates via the Sprinto library. *** #### **8. Can I map controls to a policy?** Yes. You can manually map controls or use **Sprinto AI** to suggest relevant controls. Mapping is essential to meet framework evidence requirements. *** #### **9. Why can’t I change control mappings on some documents?** Policies created from templates have predefined control mappings that cannot be modified. For uploaded documents, control mapping is allowed only after the document is approved. *** #### **10. Can I re-enable a disabled policy?** Yes. Go to the **Disabled** section in the All policies & docs tab, open the policy, and click **Enable**. *** #### **11. Can I track which employees have acknowledged a policy?** Yes. Use the **Acknowledgement status** tab to track acknowledgement progress across your organisation. You can view employee-wise and policy-wise status. *** #### 12. Can a register be mapped to multiple zones? Yes. A register can be linked to multiple zones using the multi-select zone field. *** #### 13. Do changes inside a register affect policies globally? Yes. Policy changes made within a register are reflected globally across Sprinto. *** #### 14. What happens when a register is archived? Archiving removes active register associations and deactivates linked monitors. *** #### 15. Can I send acknowledgement requests to only selected staff? Yes. You can target specific staff members using the **Select staff** option. *** #### 16. Can acknowledgement emails be customised? Yes. You can customise both the subject and message body before sending the request. *** #### 17. Can archived registers be restored? Yes. Archived registers can be restored using **Unarchive register**. *** #### 18. Are acknowledgement requests tracked individually? Yes. The Acknowledgement Status tab tracks recipient-level acknowledgement. *** #### Can employee groups be used for acknowledgement targeting? Yes. Policy applicability can be configured using employee groups from your identity provider. # Glossary This glossary defines key terms used across the Policies module in Sprinto.
TermDefinition
PolicyA formal rule or requirement that governs organisational behaviour, security, or operations.
ProcedureA step-by-step guide that outlines how to implement a policy.
DocumentA general artefact that supports compliance, such as audit reports, charters, or ISMS scope documents.
DraftThe initial stage of a document. Drafts can be edited, reviewed, and submitted for approval.
Pending approvalIndicates that a policy has been submitted for approval but is not yet active.
ActiveA policy that has been approved and is available to employees for acknowledgement.
DisabledA policy that has been deactivated and is no longer visible to employees.
ReviewerA user who can leave comments on a draft policy but cannot approve or edit it.
ApproverA user authorised to approve a policy and move it to the active state.
VersionA tracked iteration of a policy, created when changes are made after activation.
ControlA specific compliance requirement that a policy helps satisfy.
Control mappingThe process of linking a policy to one or more compliance controls for audit purposes.
Sprinto templateA prebuilt, editable policy document aligned with specific frameworks (e.g. SOC 2, ISO 27001).
LibraryA repository of standard documents that can be added to your organisation’s policy set.
AcknowledgementAn employee’s confirmation that they have read and understood a given policy.
SyncThe process of importing documents from Confluence or SharePoint into Sprinto.
MonitoringThe dashboard used to track the health and compliance status of policies and tasks.
# Overview ## Introduction Risk management is the process of identifying, evaluating, and addressing potential risks to minimise their impact on business operations. It is a critical requirement across most security compliance frameworks and helps organisations make informed decisions in the face of uncertainty. Sprinto’s built-in Risk Management module simplifies this process through intuitive workflows, pre-defined libraries, and actionable insights—ensuring a streamlined and compliant experience. ### Why It’s Important Having a robust risk management system in place is one of the most common requirements across all major security compliance frameworks. From a security compliance perspective, the risk management workflow includes: * **Risk Registration**: Analyse and define the organisation’s risk profile, along with mitigation plans, to reduce the overall impact and likelihood of risks. * **Risk Assessment**: Periodically evaluate the risk profile to identify updates driven by changes in regulations, business operations, or the threat landscape. This ensures that the risk profile evolves with the organisation’s growth and transformation. ### How Sprinto Manages Risk Management Sprinto is the perfect partner for your security compliance journey. With its built-in capabilities, managing the often tedious task of risk management becomes significantly easier. * **Risk Library**: Use Sprinto’s curated risk library to bootstrap your risk register. It includes a wide range of industry-standard risks. * **System Check**: Sprinto automatically monitors for incomplete risk assessments and alerts users to take timely action. * **Automatic Evidence Collection**: Every activity in the Risk Management module is backed by auto-collected, audit-ready evidence. * **Graphical Representation**: Risk data is presented using intuitive graphs and visuals to help you identify trends and prioritise actions. * **Uploading Risk Assessment**: Already have a risk assessment prepared externally? Simply upload it to Sprinto’s platform to complete your compliance requirements without disruption. ### Getting Started Begin your risk management journey by registering risks on Sprinto. This process includes analysing and defining relevant risks using configurable risk parameters, followed by detailing mitigation plans. You can register risks using the following methods: * Select from Sprinto’s predefined **Risk Library**. * Add **Custom Risks** manually that are specific to your organisation. * Use the **CSV Bulk Upload** option for importing risks at scale. All registered risks are then visualised on the dashboard for a clearer understanding of your risk landscape. {% hint style="info" %} You can mix and match registration methods. While the risk library is recommended for ease of use, custom risk registration is available as needed. {% endhint %} #### Related User Guides * How to Register Risk With Risk Library * How to Register Risk Manually ### Managing Risk Management Risk assessment is a continuous process of evaluating your organisation's risk profile, accounting for any operational, structural, or regulatory changes. Areas to focus on include: * **Risk Parameters**: Review and update risk attributes to reflect recent organisational changes. * **Registering New Risks**: As your organisation scales, new risks emerge. Make sure these are captured and addressed. * **Registering Custom Risks**: If standard categories are insufficient, define and register risks that are unique to your business. #### Importance of Risk Assessment Regular assessments ensure your risk register evolves with your organisation. This is a standard requirement across most security compliance frameworks. An outdated risk profile can lead to blind spots and compliance gaps. #### Risk Assessment Cycle 1. **Risk Assessment**: Periodic review and updating of registered risks. 2. **Risk Assessment Review**: Senior management reviews the assessment to ensure accuracy and coverage. This is the final step before the system marks the assessment as complete. Sprinto recommends conducting a risk assessment at least once every year. ### Use Cases
Use CaseDescription
Initial Risk Register SetupUse the risk library or bulk upload to build your organisation's first risk register.
Annual Compliance AuditPerform yearly assessments and reviews to meet SOC 2, ISO 27001, or GDPR requirements.
Business Expansion Risk ReviewUpdate risk parameters when entering new markets or launching new services.
Vendor Risk ManagementTrack and mitigate risks associated with third-party vendors.
Custom Risk ScenariosDefine and manage unique risks specific to your operations or industry.
# How it Works This article explains how Sprinto enables organisations to register, assess, treat, and monitor risks to meet security compliance requirements. ### Step 1: Register Risks You can add risks in Sprinto using any of the following methods: * **Sprinto Risk Library**: Choose from a curated list of industry-standard risks. * **Manual Registration**: Define custom risks tailored to your organisation. * **Bulk Upload**: Use the CSV upload option to import multiple risks at once. Each risk includes detailed metadata such as risk category, owner, source, CIA classification, and scoring parameters. > ⚠️ Risks added through bulk upload or manual entry must undergo scoring to become complete. ### Step 2: Score Risks For each registered risk, enter the following parameters: * **Likelihood**: Probability of occurrence before mitigation. * **Impact**: Severity if the risk occurs. * **Residual Likelihood & Impact**: Values after mitigation. Sprinto calculates both **inherent risk** and **residual risk** scores based on these parameters. The risk remains in **Incomplete** status until this step is completed. ### Step 3: Map Controls Controls are mitigation measures mapped to each risk. You can: * Manually select controls relevant to your risk. * Use **Sprinto AI** to get smart control suggestions. Controls are mapped to compliance frameworks like SOC 2, ISO 27001, or GDPR. > 💡 You can review each control’s applicability and associated framework before mapping. ### Step 4: Define Treatment Plan Each risk requires a treatment approach: * **Accept**: Acknowledge the risk and accept its residual score. * **Transfer**: Shift risk responsibility (e.g. outsourcing, insurance). * **Further Mitigate**: Plan additional actions to lower the residual score. * **Avoid**: Eliminate the risk by discontinuing related activities. Sprinto lets you assign a treatment reason and add optional notes. ### Step 5: Create Treatment Tasks For risks that require action, you can create **Risk Treatment Tasks**: * Assign tasks to Security Hub admins. * Set due dates and descriptions. * Attach evidence or add notes. Once a task is marked complete, its status updates to **Passing**. ### Step 6: Perform Risk Assessment Risk assessments must be conducted periodically (at least once a year). You can: * **Assess in-app** using the risk register. * **Upload assessment reports** from external systems. During the assessment: * Review each risk’s parameters. * Register new risks if needed. * Update control mappings and treatment plans. ### Step 7: Review by Senior Management Once the risk assessment is completed, senior management must review it: * Access the pending review card under **Security Hub > Review**. * Review all risks and assessment details. * Acknowledge the assessment to complete the process. This sets the risk assessment system check to **Passing**. # Dashboard Actions The Dashboard Actions section in Sprinto’s Risk Management module guides you through every interaction you can perform with risks inside the platform. These actions cover the entire lifecycle of a risk—from creation to closure—and ensure that your organisation stays compliant, informed, and audit-ready. *** Here’s a breakdown of the actions you can perform directly from the Risk Register and associated dashboards: ### 1. Create a Risk Register Entry Add risks to Sprinto using three available methods: * Select risks from the predefined **Risk Library** * Create **custom risks manually** * Use **CSV bulk upload** to import risks at scale This is your starting point for defining the risk profile of your organisation. *** ### 2. Score a Risk Complete risk scoring by assigning: * **Inherent Likelihood** and **Impact** * **Residual Likelihood** and **Impact** Scoring enables Sprinto to visualise the risk in heat maps and unlock further actions like treatment and assessment. *** ### 3. Map Controls to a Risk Associate specific security controls with each risk to reduce their likelihood or impact. You can: * Map controls manually by category or framework * Use **Sprinto AI** to receive automated control suggestions *** ### 4. Define and Track Risk Treatments Choose how you wish to treat each risk: * Accept, Avoid, Transfer, or Further Mitigate * Document treatment notes * Create and assign **treatment tasks** with due dates and attachments *** ### 5. Conduct a Risk Assessment Perform periodic reviews of all completed risks: * Assess risks in-app via the Risk Register * Upload an external risk register document * Submit reviewed assessments to mark the cycle complete *** ### 6. Review a Risk Assessment Senior management can review submitted assessments and formally approve them. This step finalises the risk assessment process and ensures audit trail integrity. *** ### 7. Edit or Delete a Risk You can: * Edit details like risk owner, parameters, and treatment plan before approval * Delete risks that are incomplete or no longer relevant *** ### 8. System Checks and Notifications Sprinto provides system-generated alerts for: * Unscored risks * Overdue assessments * Incomplete treatment tasks * Pending approvals These system checks help ensure you never miss a critical compliance step. *** # Create a Risk Register Entry This section describes the different ways you can create and register risks in Sprinto. You can access all these actions from the **Risks** section in the Sprinto dashboard. Here's a short video on how to set up and manage risks. {% embed url="" %} ### Add Risks from the Risk Library Sprinto offers a comprehensive, curated library of industry-standard risks. This is the quickest and most recommended way to populate your risk register. #### To add risks from the library: 1. Log in to the Sprinto dashboard and navigate to **Risks**. 2. In the Risk register tab, click **+ Add risks** and select **Add risks from Sprinto’s curated library**.
4. Browse through the available risk categories and select the risks applicable to your organisation. 5. Click **Add risks to register**.
{% hint style="info" %} Once added, each risk must be scored to complete its registration. {% endhint %} *** ### Add Risks Manually If your organisation has risks that are not covered in Sprinto’s predefined library, you can define them manually. #### To add custom risks: 1. Log in to the Sprinto dashboard and navigate to **Risks**. 2. In the Risk register tab, click **+ Add risks** and select **Add a new risk**.
3. Enter details such as: * Asset group * Risk scenario * Risk owner * Applicable CIA * Risk source * Risk managers * Exposed threats * Exposed vulnerabilities * Monetary Value * Additional information 4. Click **Add risk to register.**
{% hint style="warning" %} Custom risks must also be scored to be considered complete. {% endhint %} # Risk Registers Create and manage multiple risk registers in Sprinto to segment risks by teams, regions, or frameworks while retaining consistent risk management workflows. Multiple Risk Registers in Sprinto let you segment and manage risks across different business units, regions, frameworks, or operational contexts—without mixing unrelated risks into a single register. Each risk register functions independently, with its own set of risks, metrics, and views, while retaining the same core risk management workflows you already use in Sprinto. This capability is useful when different teams or geographies require separate ownership, reporting, or analysis of risks, but still need a consistent and auditable risk management experience. {% hint style="info" %} #### **Note** Multiple Risk Registers is an **Enterprise-only feature**. It is available exclusively on Sprinto’s Enterprise plan and is designed for organisations that need to manage risks across multiple business units, geographies, frameworks, or regulatory scopes within a single Sprinto account. {% endhint %} *** ### Key features * Create and maintain multiple risk registers from a single Risks workspace. * View high-level risk metrics for each register, including inherent risk, residual risk, effective residual risk, and treatment effectiveness. * Rename or delete risk registers as organisational needs evolve. * Manage risks within each register independently, without affecting other registers. * Use existing workflows inside a register, such as adding risks, periodic risk assessments, and configuration, without any changes to the current risk flow. *** ### Procedure #### Create a new risk register 1. Log in to the Sprinto dashboard. 2. Navigate to **Risks** from the left navigation menu. 3. On the **Overview** tab, click **Create risk register** in the top-right corner.
4. In the **Create risk register** dialog, enter a name for the risk register. 5. Click **Create risk register**.
The new risk register is added to the Risks overview and appears alongside your existing registers. *** #### Edit a risk register 1. From the **Risks** overview, locate the risk register you want to update. 2. Click the three-dot menu next to the risk register. 3. Select **Edit register**.
4. Enter the updated name. 5. Select the zones you wish to map to this register. 6. Click **Save changes**.
The updated name and mapped zones are reflected immediately on the risk register. *** #### Delete a risk register 1. From the **Risks** overview, click the three-dot menu next to the risk register. 2. Select **Delete register**.
3. Review the confirmation message. 4. Click **Delete** to confirm. {% hint style="warning" %} #### **Warning** Deleting a risk register permanently removes all risks in that register and cannot be undone. Sprinto recommends downloading or exporting the risk register before deletion if you need a reference. {% endhint %} *** #### Access and manage risks within a register 1. Click on a risk register from the **Risks** overview. 2. You are taken into the selected register, where you can: * Add and manage risks * Perform periodic risk assessments * Configure register-level settings These workflows remain unchanged from the existing risk management experience. *** #### Share risks across risk registers Share risks across multiple risk registers to reuse existing risk entries and maintain consistency across related registers. **Share risks to another risk register** 1. Sign in to the Sprinto dashboard. 2. Navigate to **Risks**. 3. Select the source risk register from which you want to share risks.
4. In the **Risk register** tab, select the required risks. 5. Click the overflow menu (three dots) above the table. 6. Select **Share risks**.
7. In the dialog that opens, select one or more destination risk registers. 8. Click **Share**.
Sprinto shares the selected risks with the chosen destination risk registers. **View shared risks** Shared risks appear in the destination risk register with a link icon next to the risk name, indicating that the risk was shared from another register. You can also use the **View** filter to switch between: * **All** – Displays all risks in the register. * **Shared** – Displays only shared risks. {% hint style="info" %} #### Note Shared risks are excluded from heatmaps if the scoring configuration differs between the source and destination risk registers. {% endhint %} *** ### Risk register status indicators Each risk register displays summary metrics to help you quickly assess its overall posture: * **Average inherent risk**: The average risk score before controls are applied. * **Average residual risk**: The average risk score after controls are applied. * **Average effective residual risk**: The adjusted residual risk based on control effectiveness. * **Average treatment effectiveness**: A percentage indicating how effective current treatments are across risks in the register. These indicators are calculated independently for each register. *** ### Reference Risks Across Risk Registers You can reference risks across multiple Risk Registers without creating duplicate records. Referenced risks remain linked to the original (source) Risk Register, allowing teams to view the same risk in multiple registers while maintaining a single source of truth. When a referenced risk is updated in the source register, the changes are automatically reflected in all destination registers where the risk has been shared. #### Share risks to another Risk Register 1. Go to **Risks** and open the source **Risk Register**.
2. Select one or more risks using the checkboxes. 3. Select the **More actions** menu and click **Share risks**.
4. In the **Share risks to register** window, select one or more destination Risk Registers. 5. Click **Share**.
The selected risks are added to the destination Risk Registers as referenced risks. #### View referenced risks 1. Open the destination **Risk Register**. 2. Referenced risks are identified by a **link icon** next to the risk name.
3. Select a referenced risk to view its details. A banner indicates the source Risk Register from which the risk was referenced. You can use the **Go to source** option to navigate directly to the original risk.
{% hint style="warning" %} #### Important considerations * Referenced risks can only be edited from the source Risk Register. * Changes made in the source register are automatically reflected in all destination registers. * Referenced risks retain their relationship with the original risk and do not create duplicate records. * Destination registers provide a read-only view of referenced risks. {% endhint %} #### Remove a referenced risk 1. Open the referenced risk in the destination Risk Register. 2. Click **Unshare**. 3. Confirm the action by selecting **Remove**.
Removing a referenced risk only removes it from the destination register. The original risk in the source Risk Register remains unchanged. *** ### Key notes * You can create multiple risk registers, but each register is managed independently. * Deleting a risk register permanently deletes all associated risks. * Risk workflows inside a register (adding risks, assessments, configuration) behave the same as in the single-register setup. * Metrics shown on the Risks overview are calculated per register and do not roll up across registers by default. --- [Next Page](/llms-full.txt/1)