ISO 27001 certification in Bangladesh starts with a practical question. Which services and information does your organization need to protect, and how can it show that its controls work? A Dhaka software company may need to demonstrate how it manages cloud production and customer support. An outsourcing company may need to show how staff receive, process and return client records. Both need a working information security management system, commonly called an ISMS, with evidence tied to the services in scope.
This guide takes a business from its first scope decision to ongoing surveillance. It covers risk assessment, the Statement of Applicability, audit evidence and the cost questions to ask when comparing certification providers. The examples are illustrative and can be adapted to software, business process outsourcing and other service organizations. For a wider overview of the certification process, see the Technotex guide to ISO certification in Bangladesh.
Define the scope around the services customers buy
Start ISO 27001 certification in Bangladesh by deciding which services the information security management system will cover. Write a short description that a customer and an auditor can both understand. A software company might include application development, production hosting and customer support for one subscription product. A business process outsourcing company might include the teams and systems that receive, process and return customer files. The legal entity, locations and functions need to match how the business actually operates.
Map the people, facilities, systems and external suppliers involved in delivering those services. Include remote work where it forms part of delivery. Identify which teams own shared services such as HR, identity administration and procurement. Even when a shared team sits outside the organizational boundary, its work may affect the security of the service inside the boundary. Write down who owns that dependency and how you obtain evidence about its operation.
Use an ordinary business transaction to test the proposed scope. Follow a new customer from contract signing through onboarding, service delivery and account closure. For each handoff, list the information transferred, the system that holds it and the person responsible for the decision. A disconnect usually appears quickly. The sales team may agree to a retention period that the platform does not support, or a support provider may be able to download data even though it does not appear in the first version of the supplier inventory.
Before requesting a quotation, compare the wording against the customer’s requirement. If a tender asks for the service being procured to be within a certified scope, a certificate covering a different product or delivery location may fail the buyer’s review. Ask for the exact procurement wording early. If the current scope cannot cover that requirement, record which additional systems or teams would need to join and who will fund that work.
Keep the scope statement with a simple boundary diagram and the record of its approval. Review these when opening a new delivery center, moving a service to a different cloud environment or transferring responsibilities to a new vendor. The diagram is useful in audit interviews because it gives people from different teams a shared reference. See Technotex’s guide to defining an ISO certification scope for questions to raise before fixing the wording.
Build a risk register that leads to decisions
The ISO/IEC 27001:2022 overview from ISO describes a management system for assessing and treating information security risks. Start with a consistent method. Agree what will be assessed, who owns each risk, how likelihood and consequence are judged, and which levels can be accepted by whom. Use definitions that people can apply to a real scenario. For example, distinguish a brief service interruption with a working fallback from a longer outage that prevents the business from meeting its contractual commitments.
Write risks as events with consequences. A line item such as “cloud” describes a dependency. A more useful entry describes a production outage caused by a failure in an externally managed service and explains which customer commitments would be affected. Capture what already reduces the risk and where evidence is weak. Record the affected information or service and identify the people who can change the process or authorize resources for treatment.
For the first assessment, work with the teams that actually handle the information. An engineering lead can explain how changes reach production. A support manager can show how customers submit attachments. HR can explain when access requests are raised for starters and leavers. Ask each person to provide a recent record. Working through actual cases is more reliable than assuming every instruction in a policy is followed in the same way across teams.
Give the business owner a clear decision to make for each important risk. The treatment could involve changing the process, reducing the likelihood or consequence, sharing part of the risk through a contract, or retaining the risk within approved criteria. Set a due date and define what evidence will show that the treatment works. A ticket marked complete tells you that a task was closed. An independently checked sample can show whether the expected result occurred.
Revisit risks after meaningful change. Examples include onboarding a new supplier, introducing a new customer data category, adding an office or learning that a recovery exercise exposed a weakness. Retain the reason for each material change in rating. This helps management see where resources made a difference and gives auditors a way to follow the assessment from its original assumptions through the latest decision.
Connect treatment to the Statement of Applicability
The Statement of Applicability, often shortened to SoA, records the controls the organization has determined are necessary, the reasons they are included and whether they are implemented. It also records the reasons for excluding Annex A controls where appropriate. Build it from the risk treatment process and check it against Annex A so that relevant controls are considered. Include necessary controls from other sources when they are needed for your scope and obligations.
Avoid copying a sample justification that says a control is applicable because it appears in the standard. Explain its purpose in your business. A supplier-related control might address outsourced customer support that processes customer records. A physical entry control might address access to an office where records are handled. A useful justification helps a new owner understand what could go wrong, where the control operates and who is accountable for maintaining it.
Keep the distinction between design and implementation visible. A policy may define how privileged access is approved. Implementation means that approvals are requested, the assigned roles are reviewed and the team can show what happens when the request is exceptional. If implementation is underway, use a consistent status and connect it to the treatment plan. Document how remaining risk is handled while the work is incomplete and who approved the decision.
Use stable references from the SoA to procedures and evidence sources. The document can refer to an access review procedure and a restricted evidence folder without containing screenshots, customer data or system details itself. That makes version control simpler and helps control how the information is shared. Where evidence may be sensitive, agree the audit arrangements in advance so the organization can demonstrate the control through an authorized review.
Test a few entries before relying on the SoA. Pick one control operated by IT, one owned by HR and one dependent on a supplier. Ask the owners to explain the reason for it, show a recent example and tell you what they do when it fails. Reconcile the explanations with the risk register. If a team cannot recognize the control description or identify evidence, change the implementation or correct the record while there is time to verify the result.
Create evidence during normal work
For certification, design the recordkeeping around ordinary operations. An auditor can sample recent transactions and compare them with the organization’s documented expectations. A pile of example forms prepared for the visit has limited value when the underlying process cannot be demonstrated. Identify the existing systems where decisions already happen, such as a service desk, HR platform, purchasing system or release tracker, and decide which parts of those records need to be retained.
For access management, assemble a small sample from the previous review period. Include a new starter, someone who changed roles and someone who left. Compare the business approval, actual access and date of implementation. If a departure was recorded late, examine how HR and IT became aware of it and what the organization did about the resulting delay. Capture the exception and its resolution in the same system that the team uses for normal work.
For resilience, pick one important service and agree what a recovery test should demonstrate. A backup completion notice is evidence that a scheduled task reported success. A restoration record can show that the intended material was recovered, checked by an authorized owner and usable within the expected conditions. Document the test scope, results, assumptions and follow-up. If the test covers a narrow component, explain how it contributes to the wider recovery plan.
For suppliers, link contracts and review records to the service they support. Note the responsibilities for reporting incidents, handling access changes and returning or deleting information when the contract ends. During a review, compare those commitments with the evidence currently available. A useful supplier register identifies who will request missing information and who can decide whether to continue the arrangement when material evidence is unavailable.
For incident management, use a tabletop scenario based on the business’s actual workflow. Record who would make the initial decision, who owns customer communication and which conditions would trigger escalation. Then record what the exercise revealed. If two teams expected each other to make the first call, assign the role clearly and retest the handoff. Keeping minutes, follow-up tasks and a completion check creates a trace from learning to improvement.
Choose a custodian for each class of evidence and record where it is stored. Agree a retrieval time for the audit and test that someone other than the person who created the record can find it. Apply your access and retention rules when sharing it. When practical, provide a reference or a suitably redacted example, with controlled access to full records only where the audit requires it.
| Activity | Evidence to retrieve | What to confirm |
|---|---|---|
| Access change | Business approval and role history | Access matched the approval and was applied on time |
| Recovery test | Restoration record and owner sign-off | The restored data was usable for the agreed purpose |
| Supplier oversight | Contract, review notes and follow-up actions | Responsibilities match how the service operates |
| Incident exercise | Scenario, decisions and completion check | Escalation and customer communication responsibilities are understood |
Prepare internal audit, management review and the external audit
Write an internal audit programme that reflects the importance of the processes and the results of earlier audits. Assign people who can evaluate the work objectively. Give them a defined scope and criteria, then ask for a sample that includes both routine work and exceptions. An internal audit of supplier management could follow one new supplier and one overdue review. That shows whether the documented approvals work both at onboarding and during the relationship.
Describe findings in a way that the process owner can act on. Record the requirement, what was sampled and what the records demonstrated. Where a requirement was missed, distinguish the immediate fix from the reason it happened. Repeating a missing approval on one ticket is an immediate correction. Addressing why a team could consistently bypass the approval is a different task. Check a fresh sample after the change and record the result before closing the action.
Use management review to make decisions. Bring the important changes, trends, audit findings, risk treatment progress and outstanding decisions to the people authorized to allocate resources. Discuss which risks deserve attention, whether current objectives still make sense and who owns the follow-up. Record the actual decisions and check completion at the next appropriate meeting. A useful review explains why an action was approved and what success looks like.
For the external audit, confirm the schedule, scope, evidence access and interview arrangements with the certification body. Stage 1 normally assesses readiness and informs planning for Stage 2. Stage 2 evaluates how the system operates in practice. Share boundary changes and major dependencies early so they can be considered in the plan. The Technotex guide to Stage 1 and Stage 2 audits explains how these stages fit into the wider certification process.
Prepare a short index that points to the current scope, risk method, risk assessment results, treatment plan, SoA, audit results and management review. Build separate pointers for operating records so teams can retrieve the requested sample quickly. Ask process owners to explain a recent transaction in their own words and show the evidence. Make a plan for any findings that may arise. Assign who will coordinate the response, who will provide evidence and who will check that corrective action is effective.
Compare ISO 27001 certification cost in Bangladesh
Prepare one brief for every certification body you contact. Include the legal entity, proposed scope, locations, approximate personnel, operating hours, remote work arrangements and relevant outsourced processes. Describe how central functions support any secondary sites. A quotation built around a short organization profile can change if the scope later expands. Confirm that each provider is pricing the same service, site coverage and audit cycle before comparing totals.
Ask which charges are included in the initial audit, such as the application, Stage 1, Stage 2 and travel where relevant. Ask separately about surveillance, recertification and additional work that may be required if findings need follow-up. Clarify how scope changes and extra locations are priced. If a quotation is in a currency other than the currency used for the project budget, ask finance how taxes and exchange movements will be accounted for. Keep the dated quotation and the assumptions alongside the comparison.
Make a separate budget for the work your organization must do. Typical budget lines are staff time, training, changes to existing tools and supplier review. Add the internal effort needed to clean up inconsistent records and run the first exercises. A team may already have most of its controls in place but lack a consistent way to collect evidence. Another may need to change approvals and ownership before generating meaningful records. These teams can receive a similar audit quotation while facing very different implementation costs.
Check the issuer’s accreditation scope when the customer requires accredited certification. Ask the provider for its legal name, accreditation body, the relevant scope and the method for verifying certificates. Confirm whether the scope on the eventual certificate will meet the customer’s requirement. The Technotex certificate verification guide gives procurement teams a reference for checking the details later.
Build the timeline from readiness milestones. Work backward from the customer’s submission date, leaving time for the organization to implement controls, gather operating evidence, complete internal audit and management review, and address any findings. Confirm the auditor’s availability before promising a date. Where the certificate is tied to a bid, ask the buyer when it must be valid and whether evidence of an audit in progress has any role in the procurement process.
| Budget line | What to request | Why it matters |
|---|---|---|
| Initial audit | Scope, site coverage and Stage 1 and Stage 2 fees | Shows whether providers are quoting the same work |
| Travel and taxes | Included expenses and separate charges | Identifies costs outside the headline fee |
| Follow-up | Terms for additional evidence review and visits | Shows how findings may affect the budget |
| Ongoing cycle | Surveillance, scope changes and recertification | Makes recurring cost visible before purchase |
Worked example for a software company in Bangladesh
Consider an illustrative Dhaka software company that sells an inventory application and provides customer support. The team runs production in a managed cloud environment and contracts a provider for support outside regular hours. An overseas customer asks whether the service it buys is covered by ISO/IEC 27001 certification. The company’s first scope draft mentions its office but says little about development, hosting or support. Management rewrites it around the application and the activities needed to deliver it.
The project lead follows one customer file through a support ticket. The team discovers that the outsourced support provider can receive attachments containing customer records. Procurement already has the vendor’s contract, but the support manager owns the workflow and no one has recorded who reviews access at the vendor. The risk owner agrees a joint process. Procurement checks contract commitments and the support manager records a recurring review of access and handling practices.
During a second walkthrough, engineering demonstrates that backups are scheduled. The risk assessment identifies that the organization also needs evidence that a service owner can use the restored data. Engineering arranges a recovery exercise, records the recovery point and validates a sample with the service owner. The test exposes a delay in contacting the person who can approve reopening the service. The team updates the call list and repeats the approval step in the next exercise.
The internal auditor samples access changes for two new starters and one leaver. The starter records are complete. In the leaver record, HR notified IT promptly but an application managed by another team was omitted from the checklist. The organization removes the remaining access, reviews similar cases and assigns someone to maintain the list of application owners. At follow-up, the auditor checks a new departure across all relevant systems. The team records both the correction and how the new control was tested.
At management review, the leadership team sees the work still open, the results of the tests and the revised supplier review process. It approves resources for a shared records repository and assigns a date for checking its use. Before Stage 1, the project lead sends the certification body the revised scope and points to where records are held. The customer receives a clear description of what is planned and a realistic timeline with separate milestones for audit activity and the final certification decision.
Maintain the ISMS after the initial audit
Assign ongoing responsibilities when the project is still fresh. The ISMS owner should know which records are reviewed monthly or quarterly, which depend on a change or incident, and which need management decisions. Use the organization’s existing planning tools to track them. A supplier review deadline should appear where procurement works. An access review should be routed to the application owner who can determine which people still need the permissions they hold.
Use measures that support decisions. An access review completion rate is useful when it identifies which applications or teams need follow-up. A count of closed incident actions is useful when paired with the age of unresolved items and a check of their effectiveness. Define where each figure comes from, which period it covers and who validates it. If the result stays unchanged because the measure cannot distinguish important exceptions, revise the measure.
Reassess the impact of organizational change before it becomes difficult to document. When the company adds a new office, launches an application or changes a key supplier, ask whether the scope, risk assessment and control ownership are still accurate. Update the relevant documents and confirm how evidence will be retained after the change. Contact the certification body about changes that may affect the certificate or audit plan and keep a record of its guidance.
Prepare for surveillance throughout the year by maintaining an indexed record of decisions and evidence. Bring open findings, significant changes and unresolved risks into the next appropriate review. The Technotex surveillance audit guide outlines the records teams can organize before the next visit. For customer requests, keep the current certificate and scope wording available through an authorized contact, with an agreed process for sharing supporting materials.
Run a short handover exercise when a key owner changes roles. Ask the incoming person to locate the current risk decisions, explain the next scheduled tasks and demonstrate how an exception is escalated. Record any missing access or unclear responsibility and close the issue through the usual work tracker. This exercise is especially useful where audit records are spread across multiple systems and the outgoing team member knows where to look from experience alone.
Frequently asked questions
What is ISO 27001 certification in Bangladesh?
It is an independent assessment of an organization’s information security management system against ISO/IEC 27001. Certification applies to the services, locations and activities identified in the certificate scope. The standard’s official designation is ISO/IEC 27001, although customers and tender documents frequently shorten it to ISO 27001. Check the scope and current certificate status when relying on certification for a supplier decision.
How much does ISO 27001 certification cost in Bangladesh?
Ask for a written quotation based on your actual scope. Audit fees depend on factors including organizational size, complexity, sites, shared functions and audit time. Compare initial audit fees with surveillance and recertification costs, then add the internal implementation budget. Use the same business profile for each quotation so differences in price can be traced to differences in coverage or assumptions.
How long does ISO 27001 certification take?
Allow time for implementation, operating evidence, internal audit, management review, the external audit stages and any follow-up on findings. Timing varies with readiness, scope and auditor availability. Ask the certification body for planning dates and identify which parts of the schedule your organization controls. If the project serves a tender deadline, confirm the buyer’s documentation cutoff before fixing the schedule.
Can a small software company get ISO 27001 certified?
A small software company can implement an ISMS and apply for certification. Start with a scope that describes the actual service and its dependencies. Use the systems the team already relies on for approvals, releases and support records. Assign clear owners for risk decisions, supplier oversight and improvement actions. Ask the certification body what it needs to plan the audit for that scope.
What is the difference between ISO 27001 and ISO 27002?
ISO/IEC 27001 sets requirements for an information security management system. ISO/IEC 27002 provides guidance on information security controls. Teams can consult that guidance when designing or reviewing a control. For the certification project, maintain a clear record of which requirements and controls apply to the scope, how the organization implements them and what operating evidence supports them.
What documents should we prepare for an ISO 27001 audit?
Prepare the scope, information security policy and objectives, risk method and results, treatment plan, Statement of Applicability, internal audit results, management review and corrective action records. Prepare operating samples relevant to your scope as well. Use an index with owners and access arrangements so the auditor can trace documents to real decisions without receiving unrelated customer or employee information.
Does our cloud provider’s certificate cover our company?
The cloud provider’s certificate covers the scope stated by that provider’s issuer. It can support your supplier review if it covers the service you use. Your organization still owns the responsibilities assigned to it by the contract and its operating model. Map these responsibilities, keep evidence of your own controls and confirm which provider records you can rely on during an audit.
How should a buyer verify an ISO 27001 certificate?
Check the issuer, certificate number, legal entity, scope, locations, edition and current validity. Use the issuer’s verification process and check the accreditation scope if your procurement rules require accredited certification. Compare the covered service to the work being purchased. If the certificate describes a different entity or product, obtain written clarification before relying on it.
Discuss your proposed certification scope
Bring your service description, legal entity, locations, approximate team size and any customer or tender requirements when you contact Technotex. Ask about current certification availability, accreditation scope where required and a quotation that identifies initial and recurring charges.
