Master Data Preparation

Your organization

We begin with the structure of the business.

Who are the departments and business functions? Where does the organization operate? Which locations are part of the environment? In which states or jurisdictions is the company authorized to conduct business?

We also want to understand how the company operates, where important responsibilities sit, and which parts of the organization may ultimately fall within the scope of the information security management system.

Useful information may include:

• Business units and legal entities
• Office and operating locations
• States and jurisdictions where you conduct business
• Departments and business functions
• Organization charts
• Key business processes
• Existing process diagrams

The objective is not simply to build a company directory.

It is to understand the organization the management system needs to support.

Your people

Information security depends on people.

We identify the leaders who will participate in the Information Security Management Team, the people who understand important parts of the business, and the subject matter experts who can help us understand how technology and processes actually work.

This may include:

• Executive and business leaders
• Employees and contractors
• Department leaders
• Infrastructure and network subject matter experts
• Application owners
• Information Security Management Team members
• Privileged users with elevated access
• IT providers and outside technical resources

We do not expect one person to know everything.

Part of implementation is finding the right person to answer the right question.

Your customers

Customers are often an important reason organizations begin their ISO/IEC 27001 journey.

We want to understand who you serve, what information customers entrust to you, and what security expectations are already being placed on the business.

• Which customers are requesting ISO/IEC 27001 certification?
• Which prospects have made certification part of their buying decision?
• Are customers sending security questionnaires or requiring specific contractual controls?
• Have opportunities been delayed or lost because the organization could not demonstrate its security posture?

Understanding these pressures helps connect the security program to something leadership already understands: the business.

Your vendors

Your security program extends beyond the walls of your company.

We begin with your vendor population and then identify the relationships that deserve greater attention.

That includes understanding which vendors provide critical business services, process or store sensitive information, have access to your systems, provide infrastructure, or could materially affect your ability to operate.

For critical vendors, we may want additional security, contractual, operational, and assurance information.

The objective is not to treat every vendor the same.

It is to understand which relationships create meaningful dependency or risk.

Your software and technology

We want to understand the technology the business depends on.

Start with your software and application inventory if one exists.

Which applications support important business processes? Who uses them? Who owns them? Which contain sensitive information? Which are cloud services? Which are internally developed? Which users have elevated privileges?

Useful information may include:

• Business applications
• Application categories or types
• Application owners
• Users by business application
• Privileged and administrative users
• Cloud platforms
• Infrastructure platforms
• Security technologies
• Document marking tools
• Data loss prevention tools
• Endpoint management platforms
• Identity platforms
• Backup platforms

If you use platforms such as Microsoft Intune, CrowdStrike, Microsoft 365, Entra ID, or other technologies that can provide operational security information, we want to understand those too.

We want to know whether document marking tools are in effect.

We want to know whether data loss prevention tools are in effect. Microsoft Purview is one example.

Those systems may eventually become important sources of evidence within Trygg.

Your AI environment

Artificial intelligence is quickly becoming another part of the organization's technology environment.

We want to understand how AI is being used rather than assume it is not being used.

• Do you have approved AI applications?
• Are employees using public AI services?
• Are AI capabilities embedded inside existing business applications?
• Has the organization established expectations around what information can be provided to AI systems?
• Who approves new AI technologies?

Even if your AI governance is still developing, understanding what is already happening gives us a much better starting point.

Your policies and processes

Bring us what already exists.

That might include formal information security policies, operating procedures, employee guidance, technical standards, process documents, or diagrams showing how important activities are performed.

We are not looking for perfect formatting.

We want to understand what the organization says it does and compare that with what people tell us actually happens.

Useful materials may include:

• Information security policies
• IT policies and standards
• Privacy related policies
• Security procedures
• Operational processes
• Process diagrams
• System diagrams
• Network diagrams
• Incident response procedures
• Business continuity and recovery documentation

Existing work has value.

Our first instinct should not be to replace it. It should be to understand it.

Your security history

Where you have been can tell us a great deal about where attention may be needed.

We want to understand meaningful security events, issues, findings, and decisions the organization has already experienced.

That may include previous security incidents, how they were investigated, what was done to remediate them, and what the organization learned as a result.

It may also include:

• Open or recently resolved incidents
• Previous audit findings
• Security assessments
• Risk assessments
• Existing risk registers
• Corrective actions
• Known vulnerabilities or security concerns

This is not about assigning blame.

It is about making sure lessons already learned become part of the management system.

Your current security work

Most organizations are already improving something.

We want to know what.

Bring us information about current or planned security projects, technology implementations, remediation efforts, process improvements, or other initiatives that may affect the management system.

We also want to understand commitments that have already been made.

That can include meeting notes, management decisions, open action items, project plans, or security related work assigned to leaders.

Trygg should not create a second universe of security work.

Where possible, the management system should reflect the work already underway.

Your risks

If you already maintain a risk register, bring it.

It does not need to look like the Trygg risk register.

We want to understand what the organization already believes could affect its information, technology, customers, operations, and business.

Existing risks, assessments, treatment decisions, accepted risks, and remediation activities give us valuable context.

If you do not have a formal security risk register yet, that is okay.

Building one is part of the journey.

Your decisions and commitments

Some of the most valuable information may not be in a formal security document at all.

Meeting minutes, leadership discussions, project decisions, budget decisions, open action items, and commitments made to customers can reveal what the organization has already decided is important.

We want to understand those decisions.

• What security actions have leaders committed to?
• What remains open?
• Who owns those actions?
• What decisions have been made about technology, risk, customers, vendors, or security investments?

A management system should preserve important decisions and make accountability visible.

The lists we gather become the owners, systems, and open commitments you and Trygg use to see what is done and what is still open.

Your security objectives

Before deciding what to measure, we need to understand what the organization is trying to accomplish.

What would a successful security program mean to your business?

• Reduce customer concerns
• Protect sensitive information
• Improve resilience
• Strengthen identity security
• Reduce operational risk
• Improve employee awareness
• Win business that requires certification
• Provide leadership with better visibility
• Build customer trust

The objectives should make sense to your organization.

ISO/IEC 27001 should support the business, not exist beside it.

Why now?

One of the most important questions we ask has nothing to do with technology.

Why are you doing this now?

• Is a customer requiring certification?
• Are prospects beginning to ask for it?
• Is leadership concerned about security risk?
• Has an incident changed the conversation?
• Is cyber insurance becoming more demanding?
• Are you entering a new market?
• Is certification part of a larger growth strategy?

We take an iterative approach, so we may not have it all figured out on day one.

Perfect is the enemy of good.