Preparing the right set of documents before a CERT-In security assessment can make the assessment process more organized and help the audit team understand your technology environment.
In this blog, we cover the key documents organizations should prepare before a CERT-In security assessment, how to organize them, common documentation mistakes, and a final checklist to help your team get ready.
1. Asset and Infrastructure Documents
A. Updated IT Asset Inventory
Maintain a current list of servers, applications, databases, network devices, endpoints, cloud resources, and other technology assets. Include relevant details such as asset owner, location, IP address, operating system, and business purposes where applicable.
B. Network Architecture and Network Diagrams
Keep updated network diagrams showing major network segments, firewalls, gateways, servers, applications, and connections between systems. These diagrams help the audit team understand how your environment is structured.
C. Server and Infrastructure Inventory
Prepare details of physical and virtual servers, operating systems, hosting locations, important services, and infrastructure owners.
D. Cloud Asset and Architecture Documentation
For cloud environments, document the services being used, account or subscription structure, major resources, network design, IAM structure, and security controls.
E. Application and Database Inventory
Maintain a list of business applications, databases, application owners, technologies used, environments, and data handled by each system.
F. Internet-Facing Asset List
Identify websites, APIs, public IP addresses, remote access services, portals, and other systems accessible from the internet.
G. Production, Development, and Testing Environment Details
Clearly separate production, development, staging, and testing environments. Include information about how these environments connect and who has access to them.
CERT-In’s comprehensive audit guidance states that audit scope should be based on a consolidated and updated asset inventory. The scope can include applications, APIs, databases, cloud architecture, networks, hosting infrastructure, and other parts of the cyber infrastructure.
2. Application and API Security Documents
A. Application Architecture Diagrams
Provide diagrams showing application components, databases, external services, authentication systems, and communication paths.
B. Application and API Inventory
List the applications and APIs that fall within the assessment scope. Include their purpose, environment, owner, and exposure where applicable.
C. API Documentation
Prepare API specifications, endpoint information, authentication methods, access requirements, and integration details.
D. Data Flow Diagrams
Document how sensitive and business data moves between users, applications, databases, APIs, cloud services, and third-party platforms.
E. Authentication and Authorization Details
Document login mechanisms, user roles, privilege levels, MFA implementation, session management, and authorization models.
F. Third-Party Integration Details
List external applications, payment gateways, identity providers, APIs, SaaS platforms, and other third-party services connected to the application.
G. Application Security Testing Records
Keep previous secure code review records, vulnerability assessments, penetration testing reports, and other application security test results.
3. Cloud and Infrastructure Security Documents
A. Cloud Architecture Documentation
Document your cloud accounts, subscriptions, major services, network architecture, workloads, and security controls.
B. IAM Roles and Access Structure
Maintain documentation of administrative accounts, user roles, service accounts, privileged access, and access approval processes.
C. Network Segmentation Details
Document network zones, VLANs, subnets, security groups, firewalls, and access restrictions between different environments.
D. Firewall and Security Group Configurations
Maintain current configuration records for firewalls, cloud security groups, network access controls, and other filtering mechanisms.
E. Server Hardening Standards
Keep documented standards for operating system hardening, administrative access, unnecessary services, password controls, and security configurations.
F. Security Configuration Baselines
Document approved configurations for servers, databases, cloud services, network devices, and other critical systems.
G. Backup and Disaster Recovery Documentation
Prepare backup policies, recovery procedures, disaster recovery plans, backup schedules, and relevant testing records.
4. Security Policies and Governance Documents
A. Information Security Policy
Provide the organization’s approved information security policy and details of how security responsibilities are assigned.
B. Access Control Policy
Document how user access is requested, approved, reviewed, modified, and removed.
C. Password and Authentication Policy
Include password requirements, MFA controls, account management procedures, and authentication standards.
D. Vulnerability Management Policy
Document how vulnerabilities are identified, prioritized, assigned, remediated, and tracked.
E. Patch Management Policy
Explain how security patches are evaluated, approved, tested, deployed, and monitored.
F. Change Management Policy
Document how changes to applications, infrastructure, configurations, and production systems are requested and approved.
G. Incident Response Policy
Provide procedures for detecting, reporting, investigating, containing, and responding to security incidents.
H. Data Protection and Privacy Policies
Include applicable policies covering sensitive information, data handling, retention, access, sharing, and disposal.
5. Logging, Monitoring, and Incident Response Records
A. Log Collection and Retention Details
Document which systems generate security logs, where logs are stored, retention periods, and who can access them.
B. SIEM and Security Monitoring Documentation
Provide details of SIEM platforms, monitoring processes, alert management, and security event review procedures.
C. Incident Response Procedures
Keep documented procedures for handling different types of security incidents, including escalation and investigation steps.
D. Incident Response Team Contact List
Maintain current contact details for security, IT, management, legal, and other teams involved in incident response.
E. Previous Security Incident Records
Where applicable, maintain records of previous incidents, investigations, corrective actions, and closure activities.
F. CERT-In Incident Reporting Procedures
Document the organization’s process for identifying incidents that require reporting to CERT-In and managing the reporting process.
CERT-In’s directions and audit guidance address logging, monitoring, incident response, and compliance with applicable CERT-In requirements. Organizations should ensure that supporting evidence is available for relevant controls.
6. Vulnerability and Security Assessment Records
A. Previous VAPT Reports
Keep previous VAPT reports covering applications, APIs, networks, cloud environments, and infrastructure where applicable.
B. Previous Security Audit Reports
Maintain reports from earlier security audits and assessments, including identified gaps and recommendations.
C. Vulnerability Scan Reports
Keep recent vulnerability scanning results and evidence showing how identified issues were addressed.
D. Penetration Testing Reports
Maintain previous penetration testing reports, including technical findings, risk ratings, and supporting evidence.
E. Open and Closed Vulnerability Records
Maintain a tracker showing which vulnerabilities remain open and which have been resolved.
F. Remediation Evidence
Prepare evidence such as configuration changes, patches, screenshots, code changes, or other records demonstrating remediation.
G. Previous Retesting Reports
Include reports confirming whether previously identified vulnerabilities were successfully resolved.
CERT-In guidance provides for follow-up audits after remediation so that identified vulnerabilities and non-conformities can be checked for closure.
7. Compliance and Certification Documents
A. ISO/IEC 27001 Certification
If applicable, keep your current certificate, scope statement, and relevant audit records.
B. SOC 2 Reports, Where Applicable
Maintain applicable SOC 2 reports and supporting documentation.
C. PCI DSS Documentation, Where Applicable
For organizations handling payment card data, keep relevant PCI DSS assessment and compliance records.
D. Industry-Specific Compliance Documents
Prepare documents related to regulatory or industry requirements applicable to your organization.
E. Previous Regulatory Audit Reports
Keep earlier regulatory assessment reports, observations, responses, and closure evidence.
F. Applicable Security and Compliance Requirements
Create a list of security requirements that apply to your organization, technology environment, customers, and industry.
8. Access and Audit Coordination Information
A. Authorized Testing Contacts
Provide the names and contact details of the employees responsible for coordinating with the audit team.
B. Application Test Accounts
Where required, prepare controlled test accounts with appropriate permissions for application testing.
C. Administrative or Privileged Test Accounts
If privileged testing is within scope, prepare authorized accounts according to the agreed rules of engagement.
D. VPN or Secure Remote Access Details
Provide approved remote access arrangements where systems cannot be accessed directly by the audit team.
E. Testing Windows and Maintenance Schedules
Share approved testing windows, maintenance periods, and any operational restrictions.
F. Rules of Engagement
Clearly document permitted testing activities, excluded systems, testing limitations, escalation procedures, and communication protocols.
G. Emergency Escalation Contacts
Provide contacts who can respond quickly if testing causes an unexpected service issue or requires immediate clarification.
9. Documents Related to Secure Application Development
A. Secure Coding Guidelines
Document coding practices that developers are expected to follow for authentication, input validation, access control, data protection, and other security areas.
B. Software Development Lifecycle Documentation
Maintain documentation showing how security considerations are incorporated into application planning, development, testing, and release processes.
C. Code Review Records
Keep records of security-focused code reviews and actions taken on identified issues.
D. Security Testing in the CI/CD Process
Document security checks performed during development and deployment, such as SAST, DAST, dependency scanning, or other testing activities.
E. Third-Party Software and Dependency Inventory
Maintain a list of major open-source libraries, frameworks, packages, and other third-party components used by applications.
F. Software Bill of Materials, Where Applicable
Where available and applicable, maintain an SBOM showing software components and dependencies.
CERT-In’s application audit guidance covers areas related to secure application design, development, implementation, and operation.
How to Organize Documents Before the Assessment?
Having documents is useful but keeping them organized makes the assessment easier to manage.
1. Create a Central Audit Repository
Store approved policies, reports, diagrams, asset lists, and supporting evidence in one controlled location.
2. Remove Outdated Documents
Review documents before sharing them with the auditor. Replace old architecture diagrams, asset inventories, contact lists, and policies.
3. Assign Owners for Each Document
Assign responsible employees for application, infrastructure, cloud, compliance, incident response, and other document categories.
4. Verify That Asset Lists Match the Audit Scope
Compare your asset inventory with the proposed audit scope to ensure that important systems have not been missed.
5. Prepare Evidence Before the Auditor Requests It
Collect supporting records in advance, so the assessment team does not have to wait for individual documents during testing.
6. Protect Confidential Audit Information
Security reports, architecture diagrams, credentials, configurations, and other sensitive information should be shared through approved and secure channels.
Common Documentation Mistakes to Avoid
1. Providing an Outdated Asset Inventory
An old asset list may exclude recently deployed applications, APIs, servers, or cloud resources.
2. Using Different Asset Lists Across Teams
Conflicting information from security, IT, cloud, and development teams can create confusion about the actual audit scope.
3. Excluding APIs or Cloud Assets from Documentation
APIs and cloud services are often closely connected to business applications and should be properly documented when they fall within scope.
4. Missing Previous Audit and VAPT Reports
Earlier findings can provide useful information about unresolved vulnerabilities and areas that require follow-up.
5. Providing Policies Without Supporting Evidence
A policy document alone may not demonstrate that the stated control is being followed. Keep relevant implementation records available.
6. Failing to Document Remediation Activities
Maintain evidence showing what was changed after vulnerabilities were identified.
7. Sharing Incomplete Architecture Information
Missing data flows, integrations, external connections, or infrastructure components can make it harder to assess the environment accurately.
Final Pre-Assessment Document Checklist
Before the assessment begins, verify that your team has prepared:
- Asset Inventory
- Network and Application Architecture
- Application and API Inventory
- Cloud and Infrastructure Details
- Security Policies
- Logging and Monitoring Records
- Incident Response Documentation
- Previous VAPT and Audit Reports
- Remediation and Retesting Evidence
- Compliance and Certification Documents
Why Choose Peneto Labs for a CERT-In Security Assessment?
Preparing documentation is only one part of an effective security assessment. Peneto Labs can work with your team to understand the assessment scope, review the relevant technology environment, and conduct security testing across applications, APIs, cloud environments, networks, and infrastructure.
Our assessment combines manual security testing and automated tools to examine technical vulnerabilities, authentication and authorization controls, API security, configuration issues, and application-specific risks. Peneto Labs also provides detailed findings and remediation guidance, followed by Free Retesting to verify the fixes implemented by your team.
For organizations preparing for a CERT-In security assessment, compliance review, enterprise customer assessment, or vendor security evaluation, having both the right documentation and the right security testing partner can make the process more organized.
If you are planning a CERT-In security assessment and need support with VAPT, information security auditing, application and API security, cloud security, network security, or infrastructure assessment, Peneto Labs can help you prepare and assess your environment.
Conclusion
Preparing documents before a CERT-In security assessment gives the audit team a clearer view of your applications, infrastructure, security controls, and compliance practices. It also helps your internal teams respond to information requests without searching for documents at the last minute.
Start by updating your asset inventory, architecture diagrams, application and API details, cloud documentation, security policies, previous assessment reports, and remediation records. Then review the information for consistency and make sure the documents match the systems included in the assessment scope.
Get in touch with Peneto Labs today to plan your CERT-In security assessment and understand the documentation and testing requirements for your organization!
Disclaimer: This blog provides general information and should not be considered legal, regulatory, or cybersecurity advice. CERT-In requirements may change, so organizations should verify the latest applicable guidelines before an assessment.