200-Day TLS Certificate Lifecycle Management in 2026
It is 8:05 on a Monday morning in February 2026. Maria, the CISO of a fast-growing fintech, opens her laptop to a wall of red alerts. The flagship payment gateway API is unreachable. Customers are reporting failed transactions. Support is overwhelmed. The first bridge suspects a cloud outage. The second suspects a WAF rule. The third finally asks the question that should never arrive this late: did a public TLS certificate expire overnight?
By 09:15, the answer is painful. The certificate was not in the configuration management database. The renewal reminder went to an engineer who left six months ago. The load balancer was deployed by a product squad, the certificate was issued through a supplier-managed account, and nobody can prove who owned the lifecycle. It is the third certificate-related outage this quarter.
The board wants a post-mortem. The ISO/IEC 27001:2022 surveillance audit is weeks away. Legal asks whether customers, regulators or supervisory authorities need to be notified. The operations team asks whether the incident could repeat on another API tomorrow. Maria realizes the root problem is not one expired certificate. It is a weak control system.
That is the real impact of 200-day public TLS certificates. What used to be a low-frequency IT task becomes a recurring operational resilience test. Organizations will renew certificates more often across websites, APIs, CDN endpoints, SSO custom domains, Kubernetes ingress controllers, cloud load balancers, webhook endpoints, email gateways and supplier-hosted portals. If lifecycle management depends on spreadsheets, personal reminders and tribal knowledge, shorter validity periods will expose the gaps quickly.
For CISOs, compliance managers, auditors and business owners, TLS certificate lifecycle management in 2026 belongs inside the ISMS. It is not just cryptography. It is asset inventory, secure configuration, monitoring, supplier governance, incident handling, privacy accountability and business continuity.
Clarysec’s approach is to treat TLS certificates as governed security assets with owners, risk criteria, renewal workflows, automated monitoring, supplier obligations and audit-ready evidence. In Zenith Controls: The Cross-Compliance Guide Zenith Controls, three ISO/IEC 27002:2022 controls form the backbone for this topic: 5.9 Inventory of information and other associated assets, 8.9 Configuration management, and 8.24 Use of cryptography. The supplied Zenith Controls extract classifies all three as preventive controls protecting confidentiality, integrity and availability, with 5.9 aligned to Identify and asset management, and 8.9 and 8.24 aligned to Protect and secure configuration.
That is the right lens for 2026. Certificate lifecycle management is asset management plus secure configuration plus cryptographic governance, evidenced continuously.
Why 200-Day TLS Certificates Change the Risk Model
A long-lived certificate environment allows bad process to hide. Renewal might happen once per year. Manual workarounds survive. A few administrators remember which portals to check. The evidence may be thin, but the failure rate feels acceptable.
Shorter public certificate validity changes that operating model. A medium-size SaaS, fintech, marketplace, healthcare platform or managed service provider can face a near-constant stream of renewals across customer-facing services and supplier-managed infrastructure. Each certificate becomes a ticking clock. A single miss can cause service unavailability, broken integrations, reputational damage, SLA breaches and audit questions.
The compliance consequences are direct.
First, asset inventory becomes evidence. An auditor will ask whether the organization knows all certificates protecting in-scope services. The answer cannot be “we think so.”
Second, automated renewal becomes a resilience control. Clarysec’s Enterprise Cryptographic Controls Policy Cryptographic Controls Policy states:
Public-facing systems must use automated certificate renewal mechanisms to prevent service disruptions.
From section ‘Policy Implementation Requirements’, policy clause 6.4.3.
Third, TLS configuration becomes testable. Certificate validity is only one dimension. Protocol version, cipher suites, certificate chain, key length, SAN coverage, CA trust and deployment target all matter. The Clarysec SME Cryptographic Controls Policy-sme Cryptographic Controls Policy - SME states:
All organizational websites must use SSL/TLS certificates with current, strong cipher suites
From section ‘Policy Implementation Requirements’, policy clause 6.5.1.
Fourth, evidence must be continuous. If certificates renew every 200 days, an annual screenshot does not prove control effectiveness. You need renewal logs, monitoring alerts, validation reports, change records, exception approvals and lessons learned.
The Enterprise Cryptographic Controls Policy makes that expectation explicit:
The Cryptographic Operations Lead shall document and maintain validation reports in the Information Security Management System (ISMS) repository.
From section ‘Policy Implementation Requirements’, policy clause 6.7.3.
The question is no longer whether HTTPS works today. The audit question is whether the organization has a repeatable, owned, monitored and evidenced lifecycle that will keep working when validity windows shrink, staff change, suppliers rotate and cloud environments scale.
The Clarysec Control Model for TLS Certificate Lifecycle Management
A mature certificate program connects inventory, procedure, automation, monitoring and evidence. The core ISO/IEC 27002:2022 control mapping looks like this:
| Lifecycle concern | ISO/IEC 27002:2022 control focus | What the auditor expects | Clarysec evidence pattern |
|---|---|---|---|
| Certificate discovery and ownership | 5.9 Inventory of information and other associated assets | Complete list of certificates, domains, endpoints, owners and business criticality | Certificate register linked to asset inventory and service owner |
| Operating procedures | 5.37 Documented operating procedures | Repeatable steps for request, issuance, deployment, renewal, revocation and emergency change | Certificate lifecycle runbook and evidence repository instructions |
| TLS deployment quality | 8.9 Configuration management | Approved TLS baseline, deviations, change records and periodic checks | TLS configuration standard, scan results and exception log |
| Expiry and drift detection | 8.16 Monitoring activities | Alerts for expiry, failed renewal and configuration drift | Monitoring dashboard, alert history and escalation records |
| Cryptographic governance | 8.24 Use of cryptography | Approved protocols, CAs, key lengths, renewal process and crypto roles | Cryptographic standard, renewal logs, CA validation and ISMS reports |
Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Controls in Action phase, Step 22, Organizational controls 5.1 to 5.18, frames the inventory problem clearly:
No organization can protect what it doesn’t know it has. Control 5.9 formalizes this foundational principle, requiring the establishment and maintenance of an up-to-date inventory of all information and associated assets relevant to the ISMS.
The same Zenith Blueprint section calls the asset inventory “the central nervous system of your ISMS” because it informs where encryption must be applied, what logs are collected, which systems require backup and how control ownership is assigned. For certificates, the inventory cannot stop at servers. The Clarysec SME Asset Management Policy-sme Asset Management Policy - SME explicitly includes:
Digital credentials and services: domain names, digital certificates, API keys, email accounts, cloud logins
From section ‘Scope’, policy clause 2.2.4.
Control 8.9 turns that inventory into secure configuration. For TLS, this means approved templates for load balancers, reverse proxies, API gateways, ingress controllers, CDN settings, mail gateways and identity platforms.
Control 8.24 completes the triangle. The Enterprise Cryptographic Controls Policy states:
A Cryptographic Control Standard shall be published and maintained, detailing approved algorithms, key lengths, supported protocols (e.g., TLS 1.2+), and system integration requirements.
From section ‘Governance Requirements’, policy clause 5.1.
For cloud-heavy environments, the Enterprise Cloud Usage Policy Cloud Usage Policy adds:
All data in transit and at rest must be encrypted using NIST-approved algorithms (e.g., AES-256, TLS 1.2+).
From section ‘Policy Implementation Requirements’, policy clause 6.4.1.
Together, these controls create a lifecycle chain. If the organization does not know the certificate exists, it cannot configure it securely. If it cannot configure it securely, it cannot prove cryptographic control. If it cannot monitor renewal, it cannot prove resilience.
ISO 27001:2022 Evidence: What Belongs in the ISMS
ISO/IEC 27001:2022 requires a management system that preserves confidentiality, integrity and availability through risk-based planning, implementation, performance evaluation and continual improvement. For TLS certificate lifecycle management, the ISMS should answer six questions:
- Which certificates, domains, endpoints and services are in scope?
- Which legal, regulatory, contractual and customer requirements apply?
- Who owns certificate risk and renewal accountability?
- Which controls are selected in the Statement of Applicability and why?
- How are certificates monitored, renewed, tested, changed and revoked?
- Where is the evidence retained?
Clauses 4.1 to 4.4 require the organization to consider context, interested-party requirements, scope boundaries, interfaces and dependencies. Certificate dependencies include certificate authorities, DNS providers, cloud providers, CDNs, identity platforms, payment processors, MSPs and MSSPs.
Clauses 5.1 to 5.3 place leadership, policy, resources, roles and reporting under top management accountability. A certificate lifecycle cannot depend on one engineer’s calendar. It needs assigned roles, communicated responsibilities and management review.
Clauses 6.1.1 to 6.1.3 require risk criteria, risk assessment, risk treatment, Annex A comparison, Statement of Applicability and residual risk approval. Practical TLS risk entries can look like this:
| Risk scenario | Impact | Treatment | Evidence |
|---|---|---|---|
| Public API certificate expires due to missing owner | Customer outage, SLA breach, incident reporting assessment | Maintain certificate register, automate renewal, monitor expiry at defined thresholds | Inventory export, renewal job logs, alert history, validation report |
| Weak TLS cipher enabled on customer portal | Data-in-transit exposure, audit nonconformity, privacy risk | Enforce approved TLS baseline and scan internet-facing endpoints monthly | TLS standard, scan report, change ticket, exception approval |
| Supplier-managed certificate not renewed | Service disruption outside direct IT visibility | Contractual certificate management requirement and supplier monitoring | Supplier contract clause, review minutes, renewal confirmation |
| Automated renewal fails due to DNS validation error | Critical service outage, emergency change pressure | Monitor renewal failures, maintain emergency revocation and renewal procedure | Alert record, runbook, incident ticket, post-incident review |
A practical ISMS evidence repository should include:
- Certificate inventory and ownership records
- Cryptographic Control Standard
- TLS configuration baseline
- Approved CA and issuance records
- Renewal automation logs
- Monitoring alerts and expiry reports
- External TLS scan results
- Change tickets and deployment approvals
- Supplier certificate obligations
- Exceptions and risk acceptances
- Incident records and lessons learned
- Management review metrics
The SME Cryptographic Controls Policy-sme reinforces the operating minimum:
The IT Support Provider must track certificate expiry dates and automate renewals where possible
From section ‘Governance Requirements’, policy clause 5.3.2.
It also states:
Certificate expiry must be monitored using renewal reminders or automated renewal scripts
From section ‘Policy Implementation Requirements’, policy clause 6.5.2.
And for auditability:
Key access logs, certificate lifecycles, and decryption test results must be auditable
From section ‘Enforcement and Compliance’, policy clause 8.1.3.
These statements translate the audit requirement into practical obligations. Track the lifecycle, monitor it, automate where possible and retain evidence.
A Two-Week Sprint to Build a 200-Day Certificate Evidence Pack
A SaaS or fintech team can make rapid progress with a focused two-week sprint. The goal is not perfection on day one. The goal is to establish a controlled baseline, remove unknowns and create defensible evidence.
Day 1 to 2: Discover and Classify
Start with DNS zones, cloud load balancers, CDN distributions, Kubernetes ingress resources, API gateways, identity provider domains, mail gateways, externally exposed IPs and supplier-managed portals. Export discovered certificates into a register.
| Field | Example |
|---|---|
| Certificate common name and SANs | api.example.com, auth.example.com |
| Business service | Customer authentication API |
| Environment | Production |
| Certificate authority | Approved public CA |
| Valid from and valid to | 2026-02-01 to 2026-08-20 |
| Renewal method | Automated ACME through cloud provider |
| Technical owner | Platform Engineering |
| Business owner | Head of Digital Services |
| Supplier dependency | CDN provider |
| Criticality | Critical |
| Monitoring status | Expiry alert enabled |
| Evidence link | ISMS repository path |
Map the register to the asset inventory. If a certificate protects a critical service but the service is not in the inventory, treat that as an asset management finding.
Day 3 to 5: Define the Baseline
Update the Cryptographic Control Standard. Include approved TLS versions, prohibited legacy protocols, approved CAs, key lengths, certificate naming conventions, renewal lead times, domain validation methods, emergency revocation steps and exception handling.
The Zenith Blueprint, Risk Management phase, Step 14: Risk Treatment Policies and Regulatory Cross-References, recommends that cryptography policy content define approved algorithms and protocols, key management, use cases, GDPR Article 32 alignment, roles and responsibilities, exceptions, enforcement and periodic review. It also recommends forbidding outdated algorithms and requiring documented exemptions with management risk acceptance.
Day 6 to 8: Automate Renewal and Monitoring
For every public certificate, decide whether renewal is fully automated, semi-automated or manual by approved exception. Public-facing systems should use automated renewal wherever feasible. Monitoring should trigger before business impact, not after expiry.
| Days before expiry | Action |
|---|---|
| 45 days | Inform technical owner and create renewal ticket if not automated |
| 30 days | Confirm renewal path and supplier involvement |
| 14 days | Escalate to service owner if not renewed |
| 7 days | Escalate to CISO or operations lead for critical services |
| 3 days | Treat as urgent operational risk and consider incident pre-alert |
| 0 days | Activate incident handling process |
Automation can use ACME, cloud-native certificate managers, CDN-managed certificates or integrated secrets platforms. The important audit point is not the specific technology. It is whether renewal is owned, monitored, tested and evidenced.
Day 9 to 10: Validate Configuration
Run external TLS scans against public endpoints. For internal services, use approved internal scanning where appropriate. Validate certificate chain, expiry, hostnames, protocol support and cipher configuration.
The Zenith Blueprint, Controls in Action phase, Step 20: Controls 8.18 to 8.26, instructs organizations to verify TLS configurations for web apps and internal services, test externally facing services for weak ciphers using SSL Labs or similar tools, plan upgrades for legacy algorithms, and document the Cryptographic Controls Inventory and Encryption & Key Management Guidelines.
Day 11 to 12: Capture Evidence and Exceptions
Upload the register, scan reports, renewal logs, change tickets and supplier confirmations to the ISMS repository. For noncompliant items, create an exception record with risk owner, business justification, expiry date, compensating controls and management approval.
Day 13 to 14: Tabletop the Failure Scenario
Run a short exercise: the main customer API certificate expires in 72 hours and automated renewal fails because DNS validation is broken. Ask who detects it, who renews it, who contacts the supplier, who approves emergency change, who communicates to customers and what evidence is preserved.
The Zenith Blueprint, Controls in Action phase, Step 23: Organizational controls 5.19 to 5.37, describes documented operating procedures as the bridge between policy and real execution. Procedures define how tasks are performed, with what tools, by whom and where results are logged. When procedures are undocumented, knowledge resides in individuals rather than systems. For certificate management, that is exactly how outages happen.
NIS2: TLS Certificates as Cyber Hygiene and Incident Prevention
NIS2 makes cybersecurity a governance and operational discipline for essential and important entities. Applicability depends on sector, size and criticality. Annex I includes banking, financial market infrastructures, digital infrastructure such as cloud computing and data centre providers, and ICT service management such as MSPs and MSSPs. Annex II includes digital providers such as online marketplaces, online search engines and social networking platforms.
NIS2 Article 20 places approval, oversight and accountability for cybersecurity risk-management measures on management bodies, with training expectations for management and employees. Certificate lifecycle management is exactly the type of basic but high-impact control that management should understand.
Article 21 requires appropriate and proportionate technical, operational and organisational measures under an all-hazards approach. TLS lifecycle management supports the following themes:
| NIS2 Article 21 theme | TLS certificate lifecycle implication |
|---|---|
| Risk analysis and security policies | Certificate expiry, weak TLS and CA compromise are assessed and treated |
| Incident handling | Expired, misissued or compromised certificates trigger defined response |
| Business continuity | Renewal automation reduces outage likelihood |
| Supply chain security | CDN, cloud, DNS, CA and MSP responsibilities are contractually governed |
| Secure acquisition, development and maintenance | TLS baselines and certificate renewal are part of change and maintenance |
| Control effectiveness | Expiry monitoring and TLS scanning prove controls work |
| Basic cyber hygiene and training | Teams understand certificate ownership and escalation |
| Cryptography and encryption | Approved protocols, CAs and key parameters are enforced |
| Asset management | Certificates, domains and endpoints are inventoried |
Article 23 adds staged significant incident reporting: early warning within 24 hours of awareness, notification within 72 hours, intermediate reporting if requested, and a final report within one month. A certificate outage may become significant if it causes severe operational disruption, financial loss or damage to others. Even if it does not cross the reporting threshold, the organization should retain incident triage evidence showing why.
DORA: TLS Certificates Inside ICT Risk and Resilience Testing
For financial entities, DORA applies from 17 January 2025 and creates a directly applicable EU digital operational resilience regime. Its scope includes credit institutions, payment institutions, account information service providers, e-money institutions, investment firms, crypto-asset service providers, crowdfunding service providers and ICT third-party service providers.
DORA Articles 5 and 6 require governance and a documented ICT risk management framework integrated into overall risk management. Certificates support availability, authenticity, integrity and confidentiality of digital services. An expired certificate can disrupt a critical or important function. A weak TLS configuration can undermine secure communication. A supplier-managed certificate can create third-party dependency risk.
DORA Articles 17 to 19 require incident management, classification, escalation, communication, reporting, root cause analysis and restoration of secure operations. A certificate-related incident should be classified using affected clients, duration, downtime, geographic spread, data impact, criticality of affected services and economic impact.
DORA Articles 24 and 25 require risk-based digital operational resilience testing, including testing of ICT tools and systems. Certificate scanning, renewal failure simulation and TLS configuration validation should be included where certificates support critical or important functions.
DORA Articles 28 to 30 bring third-party risk into focus. If a CDN manages edge certificates, a cloud provider automates renewal, an MSP controls DNS validation or an identity provider hosts a custom domain, certificate lifecycle requirements should be written into contracts and monitored in service reviews.
| DORA requirement area | Certificate lifecycle evidence |
|---|---|
| ICT risk management framework | Certificate expiry and weak TLS risks in ICT risk register |
| Incident management | Runbooks, classification records and post-incident reviews |
| Resilience testing | Renewal failure tests, TLS scans and remediation evidence |
| ICT third-party risk | Supplier clauses, audit rights, renewal confirmations and exit planning |
| Management accountability | Metrics, risk acceptance and management review minutes |
For smaller financial entities using simplified ICT risk management expectations, the lesson remains the same. Simplified does not mean informal. A spreadsheet with no owner, no monitoring and no evidence will not withstand scrutiny.
GDPR Article 32: TLS as Security of Processing
GDPR Article 32 requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. TLS is a core control for protecting personal data in transit across websites, APIs, portals, mobile apps and integrations.
The Zenith Blueprint, Risk Management phase, Step 14, states that a cryptography policy should mention support for GDPR Article 32, noting that encryption of personal data can reduce liability in case of breach. The Cloud Usage Policy requirement for TLS 1.2+ reinforces the same point for cloud services.
But GDPR evidence goes beyond “we use HTTPS.” A privacy-aware TLS evidence pack should show:
- Which services process personal data in transit
- Which certificates protect those services
- Whether processors or suppliers manage any certificates
- Whether TLS configurations meet the approved baseline
- Whether certificate expiry monitoring protects availability
- Whether incidents were assessed for personal data breach impact
- Whether weak configurations or outages were corrected and documented
An expired certificate does not automatically prove personal data was disclosed, but it can affect availability and may trigger security and breach assessment questions, especially if users are encouraged to bypass warnings or if compensating controls fail. ISO 27001:2022 provides the management system and evidence structure. GDPR provides the accountability and security of processing obligation. TLS lifecycle management is the operational bridge.
How Auditors Will Test Your Certificate Program
Different auditors ask different questions, but the same evidence can satisfy multiple lenses if it is structured well.
| Audit lens | Likely evidence request | Best Clarysec response |
|---|---|---|
| ISO/IEC 27001:2022 | Risk assessment, Statement of Applicability, asset inventory, control evidence | Certificate risk entry, mapped controls, register and ISMS repository |
| NIS2 | Cyber hygiene, cryptography, asset management, incident readiness | Board-approved policy, renewal automation, monitoring and reporting workflow |
| DORA | ICT risk, resilience testing, third-party contracts | Critical service mapping, test results, supplier clauses and incident classification |
| GDPR | Security of processing and accountability | TLS baseline, personal data service mapping and breach assessment records |
| NIST CSF 2.0 | Current and target profile, gap plan, supply chain governance | Certificate lifecycle profile and prioritized remediation plan |
| COBIT 2019 | Governance objectives, ownership, metrics and assurance | Process owner, KPIs, exception governance and management reporting |
An ISO auditor will sample certificates from the inventory and compare them to live endpoints. A DORA internal audit team will ask whether renewal failure has been tested for critical or important functions. A NIS2 reviewer will focus on management accountability, basic cyber hygiene and supplier governance. A privacy reviewer will ask whether data in transit is protected appropriately and whether incidents were assessed. A COBIT 2019-style review will focus on ownership, performance measures, exceptions and assurance.
The goal is not to maintain separate compliance programs. The goal is to create one evidence system that maps to multiple obligations.
Metrics That Make Management Care
Certificate lifecycle metrics should appear in security steering committees and management reviews, not only DevOps dashboards. They connect technical reality to board-level risk.
| Metric | Target |
|---|---|
| Percentage of public certificates inventoried | 100 percent |
| Percentage of critical certificates with named owner | 100 percent |
| Percentage of public-facing certificates using automated renewal | 95 percent or higher, with approved exceptions |
| Certificates expiring within 30 days without confirmed renewal path | 0 |
| External endpoints failing TLS baseline | 0 critical, tracked remediation for lower findings |
| Supplier-managed certificates without contractual owner | 0 |
| Certificate-related incidents or near misses | Trend down, with lessons learned |
| Exceptions past expiry date | 0 |
These metrics support ISO 27001:2022 performance evaluation, NIS2 management oversight and DORA ICT risk reporting. They also help leadership distinguish a one-off operational problem from a systemic governance weakness.
Common Failure Patterns to Eliminate
Clarysec repeatedly sees the same certificate lifecycle failures in SaaS, fintech and cloud-first organizations.
Incomplete discovery is the first. Teams know the main website certificate but miss API subdomains, staging systems exposed to the internet, CDN edge certificates, SSO custom domains, webhook endpoints, monitoring dashboards and supplier-hosted portals.
Unclear ownership is the second. Infrastructure owns the load balancer, application teams own the service, security owns the standard, procurement owns the supplier, and nobody owns renewal.
False automation confidence is the third. A certificate is “automated,” but DNS validation depends on an expired token, a decommissioned service account, a broken webhook or a provider-specific permission that nobody monitors.
Weak supplier governance is the fourth. Contracts say the supplier must provide secure services but do not specify certificate renewal, TLS baseline, incident notification, audit evidence or emergency support.
Missing exception discipline is the fifth. Legacy systems remain on weak TLS settings because “the customer still uses it,” but there is no risk acceptance, compensating control, migration plan or review date.
Evidence after the fact is the sixth. Teams scramble to reconstruct logs during audit or incident response. A mature program generates evidence as a by-product of normal operations.
Turn Certificate Renewal into an Audit-Ready Control
If your organization depends on public TLS certificates, 2026 is the wrong year to rely on manual reminders and tribal knowledge. Shorter validity periods make certificate lifecycle management a recurring operational security test. Regulators and auditors will not treat a certificate outage as harmless if it exposes weak governance, poor asset inventory, unmanaged suppliers or missing incident evidence.
A practical next step is to run a Clarysec TLS Certificate Lifecycle Readiness Review:
- Build or validate the certificate inventory.
- Map certificates to business services, owners, data types and suppliers.
- Review the Cryptographic Control Standard and TLS baseline.
- Test public endpoints for expiry, trust chain and weak configuration.
- Verify renewal automation and alerting.
- Check supplier contracts and cloud responsibilities.
- Create an ISO/IEC 27001:2022 evidence pack.
- Map findings to NIS2, DORA, GDPR Article 32, NIST CSF 2.0 and COBIT 2019 audit expectations.
- Record risks, exceptions and treatment plans.
- Prepare management reporting and continual improvement metrics.
Clarysec can help you implement this through Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls, and ready-to-adapt policies such as Cryptographic Controls Policy Cryptographic Controls Policy, Cryptographic Controls Policy-sme Cryptographic Controls Policy - SME, Asset Management Policy-sme Asset Management Policy - SME and Cloud Usage Policy Cloud Usage Policy.
The outcome is not just fewer expired certificates. It is a defensible, repeatable and audit-ready TLS certificate lifecycle management program that protects availability, supports security of processing, strengthens cyber hygiene and gives management confidence that cryptographic controls are actually working.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
