Enterprise clients evaluate a vendor's security posture before they evaluate anything else. Procurement teams send questionnaires, legal teams ask about data handling, and compliance teams want evidence that the processes described on paper actually run in practice. These reviews take time, and much of that time goes into asking questions that have standard answers.
This article puts those answers in one place. It covers how GeekyAnts identifies and resolves security incidents, how affected clients are notified, how the company keeps services running through disruptions, and what information stays confidential.
GeekyAnts holds ISO/IEC 27001, ISO 9001, and ISO/IEC 20000-1 certifications. These certifications are audited independently and cover information security management, quality management, and IT service management. The sections that follow describe how these practices work day to day.
How Security Incidents Are Identified and Resolved
Anyone can report a security incident to GeekyAnts through defined channels, which include email, helpdesk tickets, and an incident hotline.
Every reported event goes into an Incident Register, where the IT and Security teams assess its severity and scope. This first assessment decides how the incident is handled and who gets involved in resolving it.
The Incident Response Team takes over from there. Following the CISO direction, the team will investigate the incident, control it, eliminate its source and organize the recovery process. The role of IT Infrastructure in this context is to restore systems and services damaged due to the incident. In case the incident is critical, it will be escalated to the CISO and executive management so that all the decisions requiring higher-level authorizations can be made immediately.
There are incidents which involve additional steps to be taken besides technical activities. Specifically, the Legal and Compliance function assesses possible regulatory implications of the incident and makes all necessary notifications as required by the relevant laws and contracts. Other functions are involved depending on the specifics and severity of the incident. They are:
- CISO
- The Incident Response Team
- IT Security and SOC
- IT Infrastructure
- Executive management
- Legal and Compliance
- HR and Internal Audit
All functions deal with the aspects of the incident within their responsibility scope.
Incidents continue even after all systems were restored to the regular state. After an incident is resolved, a post-incident review will be performed to analyze the root cause, draw lessons and plan appropriate corrective measures. Such information will be used for improving existing controls and processes.
Taken as a whole, the process runs from the first report through assessment, response, escalation where needed, and a documented review at the end, with defined roles at every stage.
How Are Affected Clients Notified?
In case of a security event impacting the client's data or services, GeekyAnts informs the impacted client depending upon the nature of the incident, contractual agreements that are applicable, and any other legal or regulatory requirements that may be applicable. These three components put together decide what the notification should include and when it should happen.
Legal & Compliance is responsible for this process. This function determines the notifications required to be issued, creates and issues them to the clients or authorities in line with their legal or contractual requirements. Sending notifications through one single function ensures that the communication is done as per the requirement of each and every agreement.
The timing of the notification will depend on the situation at hand. The contract will define one time frame, the regulations will define another, and the nature of the incident itself would influence them both. That is why, for those clients who want a specific notification requirement, they must raise the issue at the time of contract negotiation itself.
How Does GeekyAnts Handle Business Continuity and Disaster Recovery?
GeekyAnts have defined business continuity and disaster recovery processes for key business operations and IT systems. Such processes describe what roles are responsible for recovery, what systems have higher priority, how communication will take place during disruption, and what procedures need to be followed in order to restore services. In case of any disruption, all involved teams use a pre-defined plan and do not come up with the response on the spot.
Backups lay a foundation for such capability. In case of critical systems, GeekyAnts' backups are done automatically and in an encrypted manner. The company regularly performs testing of the backups to verify that it is possible to recover from such backups and not just make sure that the files exist.
Recovery takes place against set objectives:
Objective | Commitment |
Recovery Time Objective (RTO) | 24 hours for critical systems |
Recovery Point Objective (RPO) | 12 hours for critical data |
This means that in case of disruptions GeekyAnts' critical systems get restored within a day after the disruption and maximum 12 hours worth of critical data can get lost. Once critical systems are recovered, teams verify their operation and then analyze the recovery process.
Testing is also done on the plan itself. The Business Continuity and Disaster Recovery Plans are tested through simulation or real exercises at least once a year, with feedback from the review of the test being used to identify deficiencies and recommend remedial action. The policy behind the plans is also annually reviewed, with further review following major organizational changes, disasters or audit.
These three elements, together with the backups and the objectives for recovery provide a documentable assurance of how GeekyAnts can continue operations during disruptions.
What Does GeekyAnts Keep Confidential?
Information about security practices and frameworks in public content from GeekyAnts does not go below certain limits, and this is done intentionally. There are certain types of information that remain confidential as their publication would undermine the security of the information. It includes:
- Client information
- Source codes
- Credentials
- Security framework
- Infrastructure configurations
- Incident evidence
- Logs
- Client security controls
- Information subject to confidentiality agreement
Those clients that require more information are provided with it via the appropriate channel. Client security controls and architecture are communicated directly to the particular client via proper confidentiality agreement and thus keep the sensitive information private between the parties.
A similar approach is taken in relation to the employees' use of AI tools. The internal policy on AI tool usage does not allow employees to enter confidential client information, credentials or API keys into those tools. The AI tool is treated no differently from the other external systems in this regard.
Disclaimer
Security, privacy, and compliance requirements may vary depending on the nature of the engagement, client requirements, applicable regulations, and the data being processed. Specific controls, documentation, and contractual commitments are subject to the applicable scope of services and agreement.
