Step 1) We inspect the existing rule: We record the source, destination, port, protocol, direction, action, and business purpose of the existing rule. Then, we review firewall logs to determine which legitimate systems use it.

Step 2) We define the minimum required access: We identify which systems actually need to communicate.

Step 3) You approve, we implement the change: We obtain approval from the system owner, then we apply least privilege: allow only the necessary sources, destinations, ports, and protocols to pass through firewall.

Step 4) We verify the result: We test that authorized connections still work and unauthorized connections are blocked. Then, we review firewall logs and check relevant application functionality.

Step 1) We inventory users and permissions: We review active directory, Microsoft Entra ID, Microsoft 365, local administrator groups, file shares, cloud roles, and important business applications.

Step 2) We identify excessive access: We look for privileged accounts, nested group memberships, dormant accounts, broad permissions, and roles that do not match the person’s responsibilities. We check usage logs where available; lack of recent use alone does not prove a permission is unnecessary.

Step 3) You approve, we implement the change: We obtain approval from the system owner, document the original permissions, and remove the unnecessary access.

Step 4) We verify the result: We confirm that the user can still perform required tasks but can no longer perform restricted actions.

Step 1) We identify accounts without MFA: Review your identity provider and applications to find users and administrators who can still sign in with only a password.

Step 2) We propose a secure MFA method: We prefer passkeys or FIDO2 security keys, which are resistant to phishing. Authenticator apps are also a good option.

Step 3) You approve, we enforce MFA policies: We obtain approval from the system owner, then we ask users to register their chosen authentication method. We require MFA through your identity provider, such as Microsoft Entra ID or Google Workspace.

Step 4) We test and monitor: We verify that users cannot access protected systems without completing MFA. We remove all legacy authentication methods that bypass MFA, and ensure recovery procedures work.

Step 1) We identify vulnerable services: We check running services, listening ports, software versions, and vulnerability scan results to identify vulnerable services. We determine which application or business process depends on these services.

Step 2) We identify service integration: We investigate if these services are actually needed. If they are not needed, we deactivate them. If they are needed, we consider patching or restricting access instead. If patching is not possible, we propose migration to safer services.

Step 3) You approve, we disable, patch, or migrate the service: We obtain approval from the system owner and record the original configuration. Then, we disable, patch, or migrate the service.

Step 4) We verify the service is no longer exposed: We confirm that the service has stopped, does not restart unexpectedly, and no longer accepts connections on the relevant port. We also check that dependent business applications still work.

Step 1) We identify exposed services: We inventory public websites, APIs, DNS services, VPN gateways, and other internet-facing systems. We identify which services are business-critical and what downtime they can tolerate.

Step 2) We check existing protection: We review the protections offered by the hosting provider, CDN, firewall, DNS provider, and network operator. We check whether protection is active and covers the relevant services and attack types.

Step 3) You approve, we implement traffic controls: We obtain the system owner’s approval, then we apply rate limits, request filtering, connection limits, and other controls where appropriate. We restrict direct access to protected origin servers and avoid unnecessarily exposing services.

Step 4: We monitor and test: We monitor latency, error rates, traffic volume, and service availability. We validate configurations and use controlled, explicitly authorized load tests or provider-supported DDoS simulations. We never conduct an uncontrolled stress test against production infrastructure.

Step 1) We map the network: We identify workstations, servers, domain controllers, backups, management systems, and critical applications. We document which systems need to communicate and why.

Step 2) We find excessive connectivity: We review firewall rules, network flows, remote administration services, and access-control policies. We look for unnecessary connections between user devices and sensitive systems.

Step 3) We define network segments: We define network segments according to their function and sensitivity. Typical groups include employee devices, application servers, databases, administrative systems, and backups.

Step 4) You approve, we restrict communication: We obtain the system owner’s approval, then we configure firewalls, access-control lists, and host-level policies to permit only necessary connections. For example, allow an application server to reach its database on the required port, but block unrelated workstations from doing so.

Step 5) We verify and monitor: We test that required connections succeed and prohibited connections fail. We review network logs for unexpected communication and repeat the checks after significant infrastructure changes.

Step 1) We inventory the application and API: We identify public applications, API endpoints, authentication methods, data types, dependencies, and system owners. Use API specifications such as OpenAPI where available.

Step 2) We test authentication and authorization: Check whether unauthenticated users are denied protected actions and whether one user can access another user’s records. Test different roles, such as regular user, manager, and administrator, using approved test accounts.

Step 3) We find coding and dependency weaknesses: We use static application security testing (SAST), software composition analysis (SCA), and controlled dynamic application security testing (DAST). We check HTTPS/TLS, security headers, CORS policies, permitted HTTP methods, error responses, request-size limits, etc.

Step 4) You approve, we implement changes: We obtain approval from the system owner, then we replace unsafe database queries with parameterized queries, update vulnerable dependencies, validate input according to expected schemas, and encode output appropriately. Revoke exposed secrets and rotate credentials if a leak is confirmed.

Step 5) We verify reduced API vulnerabilities: We perform configuration checks and use tests to confirm the restrictions are effective.

Step 1) We check whether the company can detect an attack: We review whether important systems generate useful security logs: identity systems, endpoints, servers, email, firewalls, cloud services, and backups. We identify critical systems, data volumes, recovery requirements, and existing backup weaknesses.

Step 2) We create incident-response playbooks We document what to do for common incidents, such as a compromised account, ransomware, suspicious email access, or a leaked API key. Each playbook should define who declares an incident, who makes decisions, how evidence is preserved, how systems are isolated, and when external specialists or authorities must be contacted.

Step 3) You approve, we implement containment actions: We obtain approval from the system owner, then we establish safe, authorized procedures for disabling compromised accounts, revoking sessions or credentials, isolating endpoints, and blocking malicious network traffic.

Step 4) We prove that recovery works: We check backup coverage, separation of backup credentials, recovery documentation, and the availability of clean systems and installation media.

Step 1) We assess existing backups: We check which systems and data are backed up, backup frequency, failure alerts, storage locations, and whether backups can be deleted by compromised administrator accounts.

Step 2) We propose a suitable solution: We recommend a dedicated backup server, off-site copies, and immutable or offline backups based on the client’s budget, data volume, and recovery requirements.

Step 3) You approve, we implement the solution: We install a dedicated backup server at the client’s premises and configure automated, scheduled backups of critical systems, servers, and business data. We secure the server with encryption, MFA, restricted access, and separate administrative credentials. We also configure off-site or immutable backup copies and automatic monitoring to detect failed backups or suspicious activity.

Step 4) We test and verify recovery: We restore files and critical systems, check data integrity, measure recovery time, and document any remaining gaps. Establish regular retesting.