Something has shifted in how people work with software. Over the past year, AI chat agents have gone from novelty to daily driver. Teams are using tools like Claude, ChatGPT, and Copilot not just to draft emails or summarize documents, but to pull real answers from real data, in real time, without switching tabs or hunting through dashboards.

The connective tissue behind this shift is a standard called MCP — the Model Context Protocol. Think of MCP as a universal adapter that lets AI agents plug into the tools and platforms your team already uses. If APIs are the plumbing that lets software systems exchange data, MCP is the fitting that lets an AI agent turn on the faucet. It gives agents structured, permissioned access to your data so they can do something useful with it — not just parrot back what’s on your screen, but actually reason over what’s behind it.

Today, we’re bringing that capability to PolicyCo.

Meet the PolicyCo MCP Connector

The PolicyCo MCP Connector lets AI agents connect directly to your PolicyCo environment. That means your team can interact with policies and procedures from inside their chat agent — Claude, for example — without ever leaving the conversation to open the platform.

Right now, the connector supports foundational capabilities: listing policies and procedures, searching across your document library, and asking natural-language questions about the content of those documents. Need to know what your data retention policy says about third-party processors? Ask your agent. Want to pull up the onboarding procedures for a specific department? Same thing.

But what makes this genuinely powerful isn’t just convenience. It’s what happens when an AI agent has structured access to the relationships PolicyCo already maintains between your policies, procedures, and controls.

Why Relationships Matter

Most organizations manage policies as isolated documents — PDFs in a shared drive, pages in a wiki, maybe a spreadsheet mapping controls to frameworks. The problem isn’t just that it’s tedious. It’s that the connections between documents exist only in someone’s head, or worse, in no one’s head at all.

PolicyCo is built differently. Every policy connects to related procedures. Procedures map to controls. Controls tie back to compliance frameworks. These aren’t loose references; they’re structured, maintained relationships that reflect how your compliance program actually works.

When an AI agent can access that relationship graph, it stops being a search tool and starts being an analyst. It can trace a question about a single procedure upstream to the policy that governs it and downstream to the evidence that supports it. It can surface connections across documents that would take a human hours to piece together manually.

Where We’re Headed

This initial release is deliberately focused. We want to get the foundation right and let real usage guide what comes next. On the roadmap: deeper analytical capabilities around risk exposure, gap identification, and cross-framework coverage — the kind of bespoke reporting that turns a policy library into a strategic asset.

The goal hasn’t changed. PolicyCo exists to give organizations a smarter way to manage policies and procedures — one built on structured relationships that can be mined for clarity, maintained as you grow, and now, queried conversationally through the tools your team already uses every day.

The PolicyCo MCP Connector is available now. Connect your account and start asking questions.

There’s a growing trend in SaaS: replace every human touchpoint with a chatbot, staff support teams as thin as possible, and hope customers figure it out on their own. For compliance software — where the stakes include audit failures, regulatory penalties, and organizational risk — that approach isn’t just frustrating. It’s negligent.

At PolicyCo, we made a deliberate choice to build something different. Not a platform that serves thousands of anonymous accounts, but a partner that knows your team, your compliance goals, and the specific challenges keeping you up at night.

Real People, Not Ticket Queues

When you have a question about PolicyCo, you reach a dedicated support resource who already understands your environment. They know which frameworks you’re mapping to, how your organization structures its policies, and where you are in your compliance journey. That means fewer explanations on your end and faster, more relevant answers — including hands-on help configuring your workspace when you need it.

This isn’t a luxury tier or an upsell. It’s how we operate for every customer.

Training That Respects Your Time

Our onboarding and training sessions are led by humans who can read the room, adjust to your team’s experience level, and field the unexpected questions that inevitably surface when compliance meets reality. We build in extensive Q&A because we’ve learned that the most valuable insights emerge from unscripted conversations — the edge cases your team encounters daily that no knowledge base article will ever cover.

Your Feedback Shapes the Product

When you submit a feature request or report a bug, it enters a transparent process with genuine two-way dialogue. You’ll hear back about prioritization decisions and timelines, not just a form confirmation that disappears into a backlog. Our product team is accessible because we believe the people using the software daily have the clearest view of what it should become next.

This feedback loop isn’t performative. Customers who look at our release notes regularly see their input reflected in the product.

The Boutique Advantage

We’re not trying to be the compliance vendor for every company on earth. PolicyCo is built for organizations that understand a compliance platform isn’t a commodity purchase — it’s an operational relationship that compounds in value over time. As your policies mature, your frameworks evolve, and your team grows, a vendor who has been in the room with you adapts in ways a self-serve platform simply cannot.

That long-term partnership creates something no AI agent or automated workflow can replicate: institutional knowledge about your organization that lives in the people who support you, not just the database that stores your documents.

The Cost of Cheap Support

Every hour your compliance team spends wrestling with unhelpful chatbots or waiting on undertrained support reps is an hour not spent strengthening your actual compliance posture. The vendors racing to cut human interaction from their cost structure are passing that cost directly to you — in wasted time, mounting frustration, and risk that quietly accumulates when questions go unanswered.

We’d rather invest in knowing our customers well than in scaling to customers we’ll never meet.

If your compliance program deserves more than a ticket number, let’s talk.

Sandra had been a home care coordinator at a regional nonprofit for eleven years. She knew the intake process cold. So when a new volunteer, David, called her confused about the emergency escalation steps in the updated onboarding procedure, she wasn’t worried. She walked him through it from memory.

Two weeks later, a client situation escalated. David followed the written procedure — not Maria’s verbal override — and called the wrong contact. Everyone was fine, eventually. But the incident report revealed something uncomfortable: the procedure itself was wrong. A phone number had changed six months ago. Nobody had updated the document.

David had noticed the number looked odd when he first read it. He had no way to say so.

The Gap Between the Reader and the Writer

Procedures are written by people who understand a process deeply. They’re read by people who are closer to the work, often finding edge cases and real-world gaps that the author never encountered. Without a channel for that knowledge to travel upstream, organizations run on documents that drift further from reality with every passing month.

The solution isn’t a rating system. Ratings tell you that something’s wrong. They don’t tell you what or how to fix it. What you need is a voice — a structured way for the person reading a procedure to say: this step is missing a decision point, or the contact here retired in March, or in our region, this works differently.

Feedback as a Living Signal

Imagine David, reading that escalation procedure on his first week, sees a small prompt: Something missing or unclear? Let us know. He types a note: “The emergency number in Step 4 doesn’t match what’s posted at the front desk. Which one do we use?”

That comment doesn’t disappear into a void. It routes directly to the procedure owner — in this case, the Director of Care Operations. She sees it flagged in her queue, alongside the specific section David was reading when he wrote it.

She responds: “Great catch, David. The front desk number is correct — we updated the system in Q3 but the procedure wasn’t synced. I’ll revise this week.”

That exchange matters. It’s not just a correction. It’s a signal that feedback is read, that the process is responsive, and that frontline workers have real influence over the tools they use. That signal makes the next person more likely to speak up.

From Comment to Release

The Director revises Step 4, marks it for internal review, and a second set of eyes approves the change. The procedure moves to a new version — not a quiet overwrite, but a tracked revision with a change summary: Updated emergency escalation contact to reflect Q3 staffing change. Flagged by onboarding volunteer.

Now the system does something important: it identifies everyone who previously attested to Version 1.2. They receive a notification. This procedure has been updated. Please review the changes and re-acknowledge.

David gets one too. He reads the update, sees his name acknowledged in the change log, and signs off. The audit trail is clean. The organization can demonstrate, if ever asked, exactly when the error was discovered, how it was corrected, and who confirmed the updated version.

Closing the Loop Is the Product

The feedback wasn’t the end of the story. It was the beginning of a process — comment, conversation, revision, release, attestation — that transformed a passive document into a living one.

Organizations that treat procedures as finished products the moment they’re published are accumulating invisible risk. The people closest to the work almost always know something the document doesn’t. The question is whether you’ve built a way for them to tell you.

PolicyCo makes that loop possible — from the first read to the final signature.

Maria had a problem. As the Operations Director for a regional conservation non-profit, she managed 500 field volunteers spread across 40 different programs—from wetland restoration crews to wildlife monitoring teams to community education ambassadors. Each program had its own set of procedures, roughly 25 per group on average. That’s 1,000 procedures, all living in a tangled web of Google Docs, shared drives, and email threads.

And every single one of them was a liability waiting to happen.

The Breaking Point

The incident that finally pushed Maria to find a better solution wasn’t dramatic. A volunteer on the invasive species removal team used an outdated herbicide application procedure. The old version had been superseded three months earlier after new safety guidelines came out. The volunteer wasn’t negligent—they’d simply downloaded the procedure to their phone for offline access back in the spring and never thought to check for updates.

Fortunately, no one was hurt. But Maria spent the next two weeks fielding questions from the board, documenting the gap in their process, and wondering how many other outdated procedures were floating around in email inboxes and phone downloads across her 500-person volunteer network.

She knew the answer: probably dozens.

The Hidden Complexity of Procedure Management

Most people think procedure management is simple. You write a document, you share it, people follow it. But Maria had learned the hard way that effective procedure management actually involves solving several interconnected problems at once.

First, there’s the writing and approval process. Procedures don’t spring into existence fully formed. They start as drafts, get reviewed by subject matter experts, require sign-off from leadership, and often go through multiple revision cycles before they’re ready for distribution. Maria’s team had no consistent way to track where each procedure was in this pipeline. Draft versions sometimes got distributed accidentally. Approved versions sat in someone’s inbox for weeks before being shared.

Then there’s version control. When a procedure changes—and they always change—you need to know exactly what changed, when it changed, and why. Maria’s team used a naming convention with version numbers in the filename, but it was honored more in the breach than the observance. She’d find documents named “Volunteer_Safety_v3_FINAL_revised_ACTUAL.docx” and have no idea if it was newer or older than “Volunteer_Safety_v4_draft.docx.” The history of how a procedure evolved over time was essentially lost.

Distribution presents its own challenges. Not every volunteer needs every procedure. The wildlife monitoring team doesn’t need the community event setup checklist. The education ambassadors don’t need the chainsaw safety protocol. Maria needed to get the right procedures to the right people—and only those people. With 40 different volunteer groups, each with different procedure sets, maintaining accurate distribution lists was nearly a full-time job.

Finally, and perhaps most critically, there’s the question of acknowledgment. Sending a procedure isn’t the same as someone reading it. Maria could email an updated procedure to 50 volunteers, but she had no way of knowing if 5 or 45 of them actually opened and read it. When something went wrong, she couldn’t demonstrate that volunteers had been properly informed. She was exposed, and she knew it.

Finding a Better Way

Maria started researching procedure management solutions with a clear list of requirements. She needed a system that could handle the full lifecycle of a procedure—from initial draft through approval, distribution, and eventual retirement. She needed rock-solid version control that would automatically track every change and maintain a complete history. She needed granular distribution controls so procedures only went to the volunteers who needed them. And she needed attestations: a way for volunteers to formally acknowledge that they’d read and understood each procedure.

What she found surprised her. Most document management tools solved one or two of these problems but not all of them. Standard cloud storage platforms offered version history but no approval workflows or attestation tracking. Email could distribute documents but created no record of who actually read them. Enterprise compliance platforms had all the features but were priced for Fortune 500 companies and designed for full-time employees, not volunteer workforces.

She eventually found a purpose-built procedure management platform that addressed each of her pain points directly. The system maintained a complete version history automatically—no more filename gymnastics. When she updated a procedure, the system incremented the version number, logged what changed, and preserved the previous version for reference. If she ever needed to see what the herbicide application procedure said six months ago, that information was two clicks away.

The approval workflow meant procedures moved through a defined pipeline: draft, review, published. Nothing went out to volunteers until it was formally reviewed, and the system maintained a record of who approved what and when.

Distribution became targeted and automatic. Maria could assign procedures to specific volunteer groups, and when she updated a procedure, only the relevant volunteers received notifications. The wildlife monitoring team got their updates; the education ambassadors got theirs. No more blast emails to the entire volunteer list with instructions to “ignore if this doesn’t apply to you.”

Most importantly, the attestation feature gave Maria something she’d never had before: proof. When volunteers received a procedure notification, they were asked to confirm they’d read and understood the content. The system tracked who had attested and who hadn’t, with timestamps and a complete audit trail. Maria could finally answer the question “did everyone on the wetland restoration team read the updated safety protocol?” with certainty instead of hope.

The Transformation

Six months after implementing her new procedure management system, Maria’s world looked different. She’d consolidated all 1,000 procedures into a single, organized platform. Each volunteer group had access to exactly the procedures they needed—no more, no less. When regulations changed or best practices evolved, she could update a procedure and have confidence that the right people would be notified and that she’d have a record of their acknowledgment.

The board stopped asking nervous questions about liability exposure. New volunteer onboarding became smoother because procedures were easy to find and clearly organized. Program managers could see at a glance which of their volunteers had completed required procedure reviews and which needed reminders.

Maria still managed 500 volunteers across 40 programs. The complexity hadn’t gone away. But the chaos had. And that made all the difference.

PolicyCo.io helps organizations like Maria’s manage procedures from creation through attestation. If you’re ready to bring order to your procedure chaos, we’d love to show you how.

Sarah drummed her fingers on her desk, staring at the email from her biggest prospect yet. TechCorp wanted to send 500 decommissioned servers to GreenCycle for secure data destruction and recycling. The contract would triple her revenue. There was just one problem.

“We’ll need to see your SOC 2 Type II report before we can proceed.”

GreenCycle had been in business for 18 months. Ten employees. No board of directors. No compliance officer. Just Sarah (CEO), two logistics coordinators, four technicians who handled the actual e-waste processing, two sales reps, and an accountant who came in twice a month.

Sarah had heard about SOC 2, but always figured it was something for “later” — when they were bigger, more established, had a real office instead of a warehouse with a corner desk area. But TechCorp wasn’t the first client to ask. If GreenCycle wanted to move beyond small business clients and tap into enterprise contracts, SOC 2 wasn’t optional anymore.

The question was: where do you even start?

The Scoping Conversation That Changed Everything

Sarah called her friend Marcus, who ran a small security consultancy. “I need SOC 2,” she told him. “But I keep reading about these massive implementation projects, governance committees, and hundreds of controls. We’re ten people, Marcus. We don’t have a board. We don’t even have an HR department.”

Marcus laughed. “Sarah, you don’t need to boil the ocean here. You need to scope your audit to what actually matters for your business. Let me ask you something: what does GreenCycle actually do with client data?”

“We track what comes in — asset tags, serial numbers, client information. We document the destruction process. We provide certificates of destruction. Everything’s in our system.”

“Okay. And where does that happen?”

“Our warehouse in Oakland. We have a small office area, but most work happens on the floor — receiving, processing, documenting.”

“Any remote work?”

“Sales team works from home. I work from everywhere. The accountant is remote.”

“Cloud services?”

“We use Google Workspace. Our tracking system runs on AWS. We use Stripe for payments. That’s pretty much it.”

Marcus pulled out a notepad. “This is your scope, Sarah. This is what you’re actually protecting for your clients, and this is what an auditor needs to examine. Everything else? Out of scope for now.”

Mapping GreenCycle’s SOC 2 Scope

Over the next hour, Marcus helped Sarah map out what would actually be included in GreenCycle’s first SOC 2 Type II audit:

In Scope:

• The Service: Client data intake, tracking, secure destruction, and certificate generation

• The System: Their custom tracking platform (hosted on AWS), Google Workspace, and Stripe

• The People: All ten employees who touch client data or the systems that process it

• The Locations: The Oakland warehouse and remote work locations for sales team

• The Data Flow: From client submission through tracking, processing, documentation, and certificate delivery

Explicitly Out of Scope:

• Physical security of the warehouse (beyond basic controls for the office area where computers were kept)

• E-waste recycling processes themselves (that was a different certification)

• Financial systems beyond what was needed for audit logging (the accountant’s QuickBooks setup wasn’t handling client data)

• Future plans for a customer portal (didn’t exist yet)

“But wait,” Sarah interrupted. “Doesn’t SOC 2 require a board of directors? Doesn’t it require separate security and compliance teams?”

“No,” Marcus said firmly. “SOC 2 requires effective controls. It doesn’t prescribe your organizational structure. You’re small. That’s fine. What matters is that you can demonstrate you’re doing the right things consistently.”

The Baseline Control Set

Marcus helped Sarah understand that for a company GreenCycle’s size, pursuing Trust Services Criteria with a focused scope, they could start with a manageable set of controls:

Security (required for all SOC 2 audits):

• Access controls for their tracking system and Google Workspace

• Password policies and multi-factor authentication

• System monitoring and logging

• Regular security updates

• Vendor security assessments for AWS and Stripe

• Basic incident response procedures

• Background checks for employees handling sensitive data

Confidentiality (relevant for GreenCycle’s service):

• Non-disclosure agreements with employees

• Secure data destruction procedures

• Encryption for data in transit and at rest

• Secure certificate delivery to clients

Sarah noticed what was missing from the list: no change advisory board (they used a simple Trello board for tracking system updates), no formal risk committee (Sarah reviewed risks quarterly with her leadership team of three), no dedicated security operations center (they used AWS CloudWatch and set up basic alerts), no disaster recovery site (they had AWS backups and a documented recovery process).

“This doesn’t look like the SOC 2 requirements I’ve been reading about,” Sarah said.

“That’s because most SOC 2 content is written by enterprise consultants for enterprise companies,” Marcus explained. “The actual Trust Services Criteria are principles-based, not prescriptive. They say you need to identify risks, implement controls, and monitor effectiveness. They don’t say you need a 40-person security team to do it.”

Making It Work Without a Board

One thing kept nagging at Sarah: “Every policy template I’ve found references board oversight and board approval. We don’t have a board. Does that kill this whole thing?”

“Not at all,” Marcus assured her. “You need governance and oversight, but it doesn’t have to be a formal board. Who owns the company?”

“I do, completely. I’m the founder and sole owner.”

“Perfect. You’re the ultimate authority. You can act as the governing body. Your policies will say something like ‘The CEO, acting as the governing authority for GreenCycle, reviews and approves all information security policies annually.’ You’ll document those reviews. You’ll show the auditor that you’re making informed decisions about risk and controls.”

Sarah felt the weight lift a bit. “So I just... approve things?”

“You govern things,” Marcus corrected. “You make informed decisions about what risks to accept, what controls to implement, and how to allocate resources. You document those decisions. You review them periodically. That’s governance. A board of directors would do the same thing — you’re just doing it as the CEO because you are the highest authority in the company.”

For management review meetings, Sarah would involve her three key people: the Operations Manager (who oversaw the warehouse), the IT contractor who managed their systems, and the Sales Director. Together, they’d review:

• Security incidents and near-misses

• Access reviews (who had access to what)

• Vendor assessments

• Policy effectiveness

• New risks from business changes

“Document those meetings,” Marcus advised. “Take notes. Track action items. That’s your evidence that you’re actively managing your security program.”

The Six-Month Journey

Marcus laid out a realistic timeline for GreenCycle’s first SOC 2 Type II:

Months 1-2: Foundation and Documentation

• Finalize scope with the chosen auditor

• Document policies (information security, acceptable use, access control, data classification, incident response)

• Implement any missing technical controls

• Set up evidence collection processes

Months 3-8: The Observation Period

• Live with the controls for six months (minimum for Type II)

• Collect evidence continuously

• Conduct monthly access reviews

• Hold quarterly management reviews

• Document any incidents or exceptions

Months 9-10: Audit

• Auditor testing and fieldwork

• Respond to auditor questions

• Remediate any findings

• Receive the SOC 2 report

“Ten months total,” Sarah said. “That’s actually doable.”

“It’s doable because you’re being realistic about scope,” Marcus emphasized. “You’re not trying to implement every control in the NIST Cybersecurity Framework. You’re implementing the controls that make sense for protecting client data in your specific business model.”

What “Light Scoping” Really Means

As Sarah worked through the scoping process, she realized “light scoping” didn’t mean “weak security.” It meant:

Focus on what matters: Client data protection for e-waste services, not every possible security control that could theoretically apply

Right-size your controls: Multi-factor authentication and password policies instead of enterprise single sign-on and privileged access management systems

Document what you actually do: Their weekly team huddles where they discussed any security issues became “management security review meetings” once they started taking proper notes

Scale appropriately: Their three-person leadership team reviewing quarterly risks was just as effective as a large company’s formal risk committee — it was just smaller

Be honest about limitations: GreenCycle’s SOC 2 report would include a clear description of what was in scope. Clients would know exactly what was being attested to.

The Payoff

Eight months later, Sarah received GreenCycle’s first SOC 2 Type II report. Clean opinion. No exceptions.

More importantly: she understood her own security program. The scoping process had forced her to think clearly about what GreenCycle was promising clients, what systems delivered on those promises, and what could go wrong. The controls weren’t busywork — they were genuine protections that made the business more reliable.

The TechCorp deal closed. Then three more enterprise contracts followed in the next quarter.

“Best part?” Sarah told Marcus over coffee. “We’re not scrambling. When larger clients ask about our security program now, I can actually explain it. When they ask about our board oversight, I explain our governance structure and they get it. When they want to know about our scope, I can articulate exactly what we protect and how.”

“That’s what good scoping does,” Marcus said. “It gives you clarity. Not just for the auditor, but for your business.”

Lessons for Your First SOC 2 Scope

If you’re approaching SOC 2 from a similar position — small team, no formal board, limited budget — here’s what GreenCycle’s experience teaches:

Start with your service: What are you actually promising clients? What data are you handling? What systems deliver your service? That’s your scope.

Don’t scope for the company you want to be: Scope for the company you are today. You can expand scope in future audits as you grow.

Governance doesn’t require a board: It requires informed decision-making and documented oversight. A CEO can provide both.

Use your size as an advantage: Smaller teams can often implement controls more quickly and consistently than large, siloed organizations.

Be explicit about boundaries: Clearly document what’s in scope and what’s not. This protects you and sets accurate expectations for clients.

Your first audit is about learning: Yes, you need the report for clients. But the real value is understanding your own security posture and building controls that scale.

Ready to scope your first SOC 2 audit? PolicyCo’s platform helps organizations of any size document their scope, map controls to Trust Services Criteria, and maintain the evidence auditors need — without enterprise complexity. Schedule some time with us to see how policy lifecycle management can support your compliance journey from day one.

We’ve been working hard to improve the PolicyCo platform. Here’s a list of features added and bugs squashed.

Features Added

Document Import

We’ve made it a lot easier to bring your word documents into PolicyCo. Before this upgrade, it was a pretty tedious process to bring in complete policies. Now, we have a way for you to upload your word document and let you set breaks for each article. You need a basic understanding of the Markdown text language, which we can walk you through one on one.

Multi Period Downloads

When you need to download gathered evidence over a range of periods (think 12 months of a year), it’s now just a few clicks in platform.

Archive / Unarchive Procedures

Sometimes you don’t need that procedure anymore. Now you can archive it with peace of mind knowing that you can come back to it at a later date and bring it back to life.

Table Width

Reproducing tables used to be a problem, but now we are more accurately setting the width of tables between the editor view and the PDF/Word exports.

ChatGPT

We’ve upgraded our platform to the latest ChatGPT model to help you converse with our platform in a natural way. This is a great way to obtain natural responses to Vendor / Third Party Assessments.

Action Plans

Sometimes a full blown action plan isn’t necessary to remediate failed evidence collection. You can now cancel an action plan if it’s not necessary.

Table of Contents and Cover Pages

Set your preference at the organization level to include or exclude, while still keeping the ability to override that setting at download.

Edit Review Cycle

Change the review cycle and the reviewer without altering the policy. Thanks to our clients for bringing this to our attention.

Bypass Period

Sometimes you need to bypass a period when gathering evidence. Think of this as an Action Plan light.

Bugs Squashed

• Improve response of audit log listing

• Attestations not showing correctly in some edge cases on the viewer

• Attestations categories improved (removed ‘superseded’ language)

• Some procedure downloads failing

• Improve keyword search across policies and procedures

• Provide ability to copy redline text for candidates

• Table rendering fixes

• Document share fixes

• Bulk author updates fixed

Introduction

In today's fast-paced business world, organizations must ensure that their employees are aware of and adhere to company policies and procedures. This is where attestations come into play. Attestations are an essential part of the governance process, as they provide a means for organizations to capture signatures from their team members, demonstrating that policies have been acknowledged and understood. In this article, we will discuss the importance of attestations in governance and accountability, with a focus on legal responsibility and the role they play in ensuring that employees are aware of company standards related to their work behavior.

The Role of Attestations in Governance

Governance refers to the system of rules, practices, and processes by which an organization is directed and controlled. It involves balancing the interests of various stakeholders, such as shareholders, management, customers, suppliers, financiers, government, and the community. Attestations play a crucial role in governance by providing a formal mechanism for employees to acknowledge their understanding of and commitment to company policies and procedures.

One of the primary objectives of governance is to ensure that organizations operate within the confines of the law and adhere to established ethical standards. Attestations help achieve this goal by creating a clear audit trail that demonstrates employees' awareness of and compliance with company policies. This not only helps organizations maintain a strong legal standing but also fosters a culture of accountability and transparency.

Legal Responsibility and Attestations

From a legal standpoint, attestations serve as evidence that employees have been informed of their responsibilities and the company's expectations regarding their work behavior. This is particularly important when it comes to policies that have legal implications, such as those related to data privacy, workplace safety, and anti-discrimination.

For example, ensuring that employees have signed an acceptable use policy (AUP) is crucial for organizations that handle sensitive data or operate in highly regulated industries. An AUP outlines the acceptable use of company resources, including computer systems, networks, and electronic devices, and helps protect the organization from potential legal liabilities arising from unauthorized or inappropriate use of these resources. By obtaining employee attestations for the AUP, organizations can demonstrate that they have taken the necessary steps to inform employees of their responsibilities and expectations, thereby reducing the risk of legal issues and potential penalties.

Similarly, attestations can play a critical role in demonstrating compliance with workplace safety regulations. By obtaining employee signatures on safety policies and procedures, organizations can show that they have made a concerted effort to educate their workforce on safe work practices and have taken the necessary steps to minimize the risk of accidents and injuries.

Attestations and Accountability

In addition to their legal benefits, attestations also promote a culture of accountability within an organization. When employees sign off on company policies, they are effectively acknowledging their understanding of the rules and their commitment to abide by them. This not only helps to ensure that employees are aware of their responsibilities but also fosters a sense of ownership and personal accountability for their actions.

Moreover, attestations can serve as a valuable tool for management to gauge employee engagement and identify potential areas of concern. For instance, if a significant number of employees have not signed off on a particular policy, this may indicate a lack of understanding or awareness, signaling the need for additional training or communication efforts.

Implementing an Effective Attestation Process

To fully realize the benefits of attestations in governance and accountability, organizations must implement an effective attestation process. This includes:

1. Establishing clear and comprehensive policies: Organizations must develop well-defined policies that outline employee responsibilities and expectations. These policies should be easily accessible and written in a language that employees can understand.

2. Communicating policies to employees: It is essential to ensure that employees are aware of company policies and understand their implications. This may involve conducting training sessions, distributing policy documents, or using digital platforms to disseminate information.

3. Obtaining employee attestations: Organizations should establish a formal process for obtaining employee signatures on policy documents. This may involve using digital tools, such as electronic signature platforms, to streamline the process and maintain a secure audit trail.

4. Monitoring and enforcing compliance: Management must regularly review employee attestations to identify potential areas of concern and take appropriate action to address any issues. This may involve conducting audits, providing additional training, or implementing disciplinary measures for non-compliance.

5. Continuously updating and improving policies: Organizations must regularly review and update their policies to ensure that they remain relevant and effective. This may involve soliciting employee feedback, monitoring industry trends, and staying abreast of changes in laws and regulations.

Learn more...

Conclusion

Attestations are a vital component of the governance process, serving as a means to demonstrate legal compliance and promote a culture of accountability within an organization. By implementing an effective attestation process, organizations can not only protect themselves from potential legal liabilities but also foster a transparent and responsible work environment that benefits all stakeholders.

We recently released our attestations module.

It’s almost impossible to calculate the time individuals spend ensuring policy consistency across an organization. We painstakingly attempt to follow style guides to underscore brand uniqueness. Templates for decks, docs and spreadsheets help, but they are limited because content creators can override template styles.

When writing policy and procedures, content is king. Policies and procedures demand consistency. Font face, size, styles, sections, titles, table of contents, headers, footers, and numbered lists need to be the same across all documents.

Even for a small organization with dozens of policies, maintaining consistency requires dedicated clerical intervention with a critical eye. Even a very small change like adding an underline to every H2, requires opening every policy to make the style change. Imagine combing through scores of policies to ensure numbered points are setup as 1.(A)(i) instead of 1.2.3. The problem is compounded with large organizations.

PolicyCo documents inherit styles from a single source of truth set at the organization level. All styles are set from one place for all documents. Practically, this means your team can write content without the distraction of setting styles. Additionally, you gain the flexibility to change your mind by changing styles for the organization, updating every policy at once. Coupling this with our article-first approach to building policy, the table of contents is also constructed based on your established hierarchy.

Also, our document classification feature has the capability to add custom headers and footers to different document classifications in minutes rather than hours.

We recognize that maintaining policy is different from creating word documents and we developed a platform that specifically caters to the needs of policy writers. Don’t estimate the hidden costs of busywork. If you’d like to learn more visit us at PolicyCo.io.

Homogenize the Enterprise was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Maintaining your compliance posture is hard work. There are many personalities and competing interests. Business Development wants to grow. Operations needs to be nimble. Product wants to innovate and be reliable. Legal strives to stay out of trouble. Leadership needs to manage the big picture. These competing interests naturally create silos of information.

One of the greatest challenges to a compliance program is mining these silos and associating them in some meaningful way to policy. Further complicating this, we recognize that the information and activity in each silo is dynamic often changing on a daily or weekly basis. Some examples include:

• Onboarding and offboarding procedures

• Data architecture diagrams

• Customer service procedures

• Devops procedures

• IT procedures and support guides

• Purchasing and finance guidelines

Policies are generally managed by legal or compliance teams. It’s not uncommon to see outdated procedures tied to policy to keep up with changes to each silo.

Modern Problems Require Modern Solutions

Departments need autonomy when writing procedures, runbooks and process manuals. Managers often use Word or Google Docs and distribute them via email or from a shared drive. Technical teams may opt for Confluence, Github (via readme.md) or Dropbox. These are all great solutions and should continue to be used, but they need some sort of glue to hold them together to ensure your policies have procedural coverage.

PolicyCo addresses this need by giving your departments independent access to write and share procedures. Department members are able to write procedures and submit them for approval to their manager. Managers can grant access to the department or extend access to the organization.

“Finally, the compliance team can stop chasing down outdated procedures. This means less work for everyone.”

Compliance needs to make sure procedures are current. Once a procedure is created, compliance can link it directly to policy. Now, procedures are maintained in real time by departments while legal/compliance benefits by eliminating the upkeep. It’s a win-win for the enterprise.

Policy can be exported with or without procedures attached, depending on the specific need. Further, employees can browse or search procedures with a lightweight mobile-friendly viewer improving knowledge transfer across the organization.

The Champion

Stop fighting the silos and embrace your various systems by recording where procedural source of truth lives.

It takes an operational mindset to address growing inefficiency in an organization. If you are the champion for your organization and are interested in solving this problem, we’d love to talk.

Cooperative Compliance Across the Enterprise was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Your organization is an ecosystem of interworking parts; a vast collection of automated and manual agents, ideally pointed in a direction with the intent of improving your chances for success or optimizing market value. Healthy organizations spend an immense amount of time documenting their inner workings though training both verbal and written. But how do we determine if your activities are contributing to positive change?

Obviously, policy plays an important role. SOC2 addresses many of the key points required to operationalize your workflow. It codifies board involvement, hiring, operational flow and security just to name a few. Even with all its strengths, an organization cannot realize the full benefit without oversight.

Oversight

Mature organizations understand the benefits of meaningful oversight. The connotations of oversight range depending on one’s perspective. It’s understandable for an employee to feel mistrusted if their work is always scrutinized by a third-party. As a leader, it’s important to focus on organization excellence and how oversight can unearth meaningful data to inform decisions leading to better outcomes.

At this point, it’s important to visualize an example of oversight applicable to your organization. Let’s assume that your organization conducts background checks on individuals and maintains standards related to the results of those investigations. We can break this down and follow the path through, control, policy, procedure and evidence.

• Control. SOC2 CC1.4.2 contains relevant language related to an employee’s background. While this control isn’t completely prescriptive, it makes that point that you, as an organization, make every effort to hire individuals who have the skills needed to perform their intended job function.

• Policy. If we look to your Workforce Onboarding and Clearance policy, we are likely to find an article related to the Scope of Background Investigations. This article must state the organizational requirements; in this case, that a background check must be performed, reviewed, and stored.

• Procedure. This is where the substantive language begins. The procedure outlines specific steps, vendor names, individual or roles and, properly written, allows for little to no room for interpretation.

• Evidence. (also known as control tests) Evidence captures procedural activity demonstrating that procedures are followed as written. Referring to our example, this might be a list of current employees cross referenced to a list of background checks. Do we have a 1–1 match? If we have standards for rejection based on the background check findings, did we follow those standards?

The steps above are all critical to your compliance effort, but getting to finish line requires several more important steps.

Accountability

Let’s focus on the last step, evidence. I’m going to make a case here for the importance of separation of duties for automated and manual evidence gathering. It’s great when we use API’s to automate gathering routine evidence month after month. For information we cannot gather automatically, we must gather manually.

Automation breaks. Who holds accountable the programmer responsible for the script when it stops functioning as expected or when the returned data is not longer relevant?

Manual processes become outdated. Who reviews manual evidence and compares it to the procedural language to ensure that it satisfies the spirit of the connected procedures, policy and controls?

The answer to both questions points to an independent review process. This means that the person or process gathering evidence must not also bear the responsibly for verifying accuracy. This distinction lays the groundwork for how Management Action Plans can transform your organization.

Self Improvement

Athletes don’t excel by being complacent. It’s a daily routine of self critique, analysis, and a will to improve. Organizations are no different. Oversight highlights weak processes by shedding light on procedural shortfalls, but awareness is only the first step. Next, we must devise a plan to remediate.

Management Action Plans do exactly this. They set into motion a chain of custody between the reviewer and the procedural stakeholder ensuring that steps will be taken according to mutually agreed upon timelines, to resolve failed control tests.

Let’s look at our previous example to see how a Management Action Plan might be used to resolve a failed control test.

• Assignee submits the results of employee background checks monthly.

• Reviewer views each background check and finds that there are 3 employees on the new hire list without a background check on file.

• Reviewer fails the period and sets in motion a Management Action Plan. At this stage, the reviewer (1) crafts a narrative explaining the nature of the failure; (2) assigns a plan Author with the necessary skills to write the plan and; (3) sets a due date for the written plan. “I’m seeing 3 employee background checks missing from February. Please explain why and how you expect to resolve this in the future.”

• The Author is now required to submit their plan by the prescribed date. The Author must also provide an estimated plan completion date. This plan is not considered approved until the initial reviewer accepts the plan. “We changed to a new vendor in mid February and our new vendor isn’t sending the to us. I will notify the vendor to get the missing three background checks and will ask them to setup and automated process to place these in the correct location upon completion.”

• Once the plan is complete, the Author is again responsible for explaining the details of the completion, and this too, is subject to reviewer approval. “Our new vendor was able to provide the past reports and they have agreed, and I have verified that reports are going to the correct location.”

The example above represents a straightforward use case. Management Action Plans can be very complex involving months or years of planning to remediate. It’s plausible that an organization might consider modifying policy or procedures in order to accommodate limitations around evidence gathering activities.

I hope this article has helped you better understand how Management Action Plans can help you and your team think critically and use that information to continually aim for excellence. Reach out to us to learn more.

How Do Management Action Plans Lead to Organizational Excellence? was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

A well-prepared cybersecurity program can minimize threats; however, a company can never eliminate risk due to the human factor. For example, the CIOX incident from July 2021 was from a single email account and yet affected thousands of individuals. Cyber threats have evolved to become more organized and sophisticated, so what happens after a large-scale incident is reported?

Activate the Incident Response Plan

The incident response plan outlines the steps and phases of what to do when a breach has occurred. It also establishes a communication channel so the organization knows who to notify in the event of a violation. A well-established plan should include performing mock sessions and reviewing the plan annually. One of the first steps in any incident response plan will consist of updating the team with as much information about the breach as possible, including:

• How was the threat discovered?

• What areas does this impact?

• Who discovered it?

• When was it first noticed?

Isolation and Eradication

During this time, the team will collect any available data from applications and interview anyone involved with the breach. The team will identify the threat and contain it to prevent further damage. Depending on the nature of the breach, this could include short-term and longer-term containment strategies. Once the team removes the threat, the team will identify the root cause to prevent similar attacks in the future (e.g., patching a system, resetting passwords, or removing malware). Depending on the nature of the episode, you may need to consider engaging with a forensic firm that can identify all areas impacted. For example, a breach of an email account could have further repercussions because a hacker could have spoofed and sent emails to other individuals gaining access to additional accounts.

Analysis of legal requirements

Once the team eradicates the threat, the team needs to review legal and regulatory requirements. Whether there are legal requirements is likely dependent on the type of data exposed and accessed (e.g., Did this involve PHI? Was client data accessed?). Review your contract matrix to determine the notification period and contact details. Identify what regulations you might need to follow (e.g., Do you need to report this to a government entity?). If the analysis concludes the external individuals are affected, you should seek legal counsel. Additionally, depending on the extent of the breach, you may need to notify your cyber liability insurance carrier.

Notification

You will need to start informing victims and relevant government entities at this stage. If the breach is extensive and includes PHI, you might be obligated to report it to the media to comply with HIPAA regulations. You may consider hiring a PR firm to orchestrate the messaging and your legal team. If you are a business associate, you should be prepared to provide enough information to the covered entity to identify all individuals impacted by the incident. Before sending notifications, prepare statements that address frequently asked questions (e.g., Why did this happen? What is the company doing to ensure this does not happen again? Who was involved?). The organization needs to identify which employees can answer questions about the breach and whether they are confidential or still under development. If multiple individuals are involved, you may want to consider setting up a call center that is prepared to answer frequently asked questions. A breach notification can also lead to an external audit. You will want to secure all evidence gathered related to the breach and ensure your policies and procedures are up to date.

Lessons Learned

The incident response team will want to regroup and minimize future threats. Determine the root cause of the breach, identify the risk to eliminate through policy changes, updates, or purchasing cyber security tools, and perform an internal audit to identify additional risks. Need assistance creating an incident response plan or organizing your policies? Contact PolicyCo for help.

How to Survive a Compliance Incident was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Policy architecture is complex, and the difficulty is compounded as your organization attempts to comply with more regulations and frameworks. Ambiguity tends to be the culprit here. Fundamentally, we as humans like to fit things into a neat classification system. However, there is a mountain of terminology to master, and even then, we still often find that certain pieces of policy language can apply to more than one area.

The only reasonable way to navigate multiple control frameworks is to normalize framework concepts into your policy statements. That’s a mouthful, so let’s take a minute to break down the statement.

Normalizing Framework Concepts

A mathematician might think of this as finding the least common denominator, which is easy because there is a correct answer. In our world, it’s more complicated. We must rely on our interpretation of framework concepts to craft an appropriate policy statement. Let’s get started with a relatively straightforward example. Each of the controls listed below talks about the concept of encrypting data as it traverses a network. Some are more prescriptive, and others are more general. Note that HITRUST and CIS are very specific about the use of WPA2.

• HITRUST 0502.09m1Organizational.5 — Wireless access points are configured with strong encryption (AES WPA2 at a minimum).

• CIS 12.6 — Use secure network management and communication protocols (e.g., 802.1X, Wi-Fi Protected Access 2 (WPA2) Enterprise or greater).

• PCI DSS 4.1.1 — Encrypt transmission of cardholder data across open, public networks

• SOC2 CC6.7.2 — Uses Encryption Technologies or Secure Communication Channels to Protect Data — Encryption technologies or secured communication channels protect data transmission and other communications beyond connectivity access points.

• HIPAA 164.312(e)(2)(ii) — Implement a mechanism to encrypt electronically protected health information whenever deemed appropriate.

Let’s try to craft a policy statement (we call it an article) in our Wireless Security Policy that normalizes the above language for our use. We can accomplish this by looking at the concepts above and including those concepts that are common to all in our statement. Concepts: encryption, transit, wireless. This can get tricky because several of the controls above make no mention of wireless. It’s our responsibility to understand that transmission can happen over wired or wireless networks.

“Wireless access points must be configured with strong encryption. At a minimum, AES WPA 2 must be configured.”

The process of normalizing policy language is compelling. It means that we can state our intentions in our vernacular while adhering to principles defined by others.

So if we were to take our newly crafted article and bring it into our Wireless Policy, it might look like this:

1.3 Wireless Encryption

Wireless access points must be configured with solid encryption. At a minimum, AES WPA 2 must be configured.

HITRUST 0502.09m1Organizational.5

CIS 12.6

PCI DSS 4.1.1

SOC2 CC6.7.2

HIPAA 164.312(e)(2)(ii)

We’ve responsibly displayed the article and all applicable controls. The problem is that we wrote this in Word or Google Docs, which means these are just words on a page. There is no meaning embedded in these concepts, which means additional repetitive work for everyone. For example:

• We don’t know that Wireless Encryption is the third article in the policy

• We don’t know that this article is linked to 5 different framework controls

• We don’t know the meaning or definitions of these controls

Procedures

Different frameworks place varying emphasis on the presence of procedures. At PolicyCo, we strongly feel that each article should be accompanied by at least one procedure; after all, the article states what you intend to do while the procedure explains how you plan to go about it.

The incredibly vital part of admitting that you need a procedure is knowing that you only need to write it once to satisfy all the controls mapped to the article. In our example above, the procedure for ensuring that wireless access points are encrypted is as follows:

“Encryption is enforced through the Meraki wireless configuration dashboard at https://meraki.com. The dashboard enforces WPA2 for all access points, and the IT Director is in charge of the setup and enforcement of this security setting.”

This procedure, as written, states who is responsible for the execution and where to access the setting. We only had to write the procedure once to satisfy Article 1.3 plus the five related controls.

Evidence (Control Testing)

In much the same way procedures benefit from being tied to a single article, Evidence (Control Testing) benefits. The only responsible way to verify that procedures are being followed is to provide evidence of the activities described in the procedure. Interestingly, by the time we arrive at the description for testing, we don’t care much about the meaning of the controls. Our only responsibility is to validate that the procedure is being followed. This test follows a logical path back to the control (Evidence: Procedure: Article: Control).

Build Relationships

It’s an excellent motto for life and policy management. The only responsible way to tame multiple control frameworks is to normalize your internal language and build these relational connections. The process takes time, and careful consideration, but the rewards come in the form of peace of mind, productivity gains, and preparedness.

• For a given control, which policies are referenced (and where is it in the policy)?

• How many controls and frameworks are applicable for a given article within a policy?

• Do I have control requirements without policy associations?

• Am I missing procedures for some controls/articles?

• Am I collecting Evidence (Control Testing) for all of my controls required?

Those are just five questions, but we can answer dozens more by exploring the rich relationships created in the PolicyCo platform.

Originally published at https://policyco.io on January 4, 2022.

Navigating Multiple Control Frameworks was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

According to Tenable, over 44% of organizations use more than one security framework. Mapping controls from one framework to another is complex and adding to the complexity is the ambiguity of terms across the frameworks. Some frameworks have defined controls to follow, while others offer guidelines. At PolicyCo, we have created a mapping system that standardizes the terminology allowing us to easily map more than one framework to a procedure, policy, or piece of evidence. This required us to dissect the nuanced differences between the security frameworks allowing an organization to follow multiple frameworks while reducing the redundancy across an organization’s cybersecurity program. Below is the glossary of terms specific to mapping security frameworks back to the evidence, policies, and procedures.

ISO

• Standards: Specifications that similar organizations can use to ensure materials, products, processes, and services meet industry best practices

• Clauses: Sections containing specific requirements and processes.

• Controls: Safeguards to reduce security risks

SOC 2

• Criteria: An individual specification

• Category: Sections containing a set of specific criteria related to an aspect of the security program

• Internal Control: An organization’s objective to protect information security

HITRUST

• Category: Section containing specifications and objectives for information security and risk management

• Domain: Organized sections based on standard IT organizational structure

• Objective: Statement of the intended result

• Specification: Policies, procedures, guidelines, practices, or organizational structures, which can be operational, technical, or legal

• Reference: An individual requirement/ control

NIST

• Function: Organized cybersecurity activities and outcomes

• Category: A subdivision of a function that contains cybersecurity objectives

• Subcategory: Outcome driven statements and security controls

• Informative References: Detailed technical resources used to support implementing subcategories

PCI

• Goal: Organized section of requirements that state the intended result

• Requirement: Organized sections of security protocols/controls for securing data

• Sub-requirements: The specific security control for obtaining data

• Compensating Control: A similar method for adhering to the requirement utilized when an entity cannot meet the requirement as expressly stated

• Guidance: The core purpose of the requirement and additional content to assist in the definition of the requirement

Manage Multiple Frameworks with PolicyCo

Cybersecurity compliance can be overwhelming; hopefully, we’ve cleared up some confusion on the language used by some of the most popular frameworks. If you are struggling with managing multiple cybersecurity frameworks, PolicyCo can help. Our platform streamlines compliance processes across frameworks for organizations, and our vCISO team has extensive experience developing cohesive policy language from a variety of framework controls. Contact us for more information.

Originally published at https://policyco.io on December 14, 2021.

The Ambiguity of Compliance Terms was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Writing and reading employee handbooks can be tedious, so it isn’t surprising that many small businesses skip over them entirely. When your team is small, it may seem easier to talk about ideas, policies, and procedures as they come up in an ad-hoc way.

However, employee handbooks are useful for many reasons. Avoiding working on one because it’s not fun can cause you pain and strife down the road, including high staff turnover or even lawsuits. Effective handbooks clearly state expectations between the employer and employee. When everyone is on the same page, there are fewer risks to the employee, the employer, and the business as a whole. As a small business owner, to have a basic boilerplate employee manual. It needs to be both useful and engaging. If it doesn’t meet those two criteria, it’s probably not going to get read. It’s not going to do you any good if it just sits on a shelf collecting dust.

The basic purpose of an employee manual is to get everyone on the same page when it comes to expectations. Employees need to understand what their role is within the business and how they’re expected to reflect the values of the brand. When expectations are clearly stated upfront, you will be better able to recruit quality employees and prevent high turnover. In an increasingly millennial workforce, this is crucial. According to a study from Gallup, 21% of millennials say that they have changed jobs within the past year. That number is three times higher than non-millennials. Preventing turnover is essential today. It’s important that you only include the information that your employee absolutely needs. Employees will be much more likely to read through an entire employee manual if it is focused and relevant to their position. For instance, Nordstrom’s employee handbook contains only one rule: “Use good judgment in all situations.” If that’s all you need, then that’s all you need. Don’t bog down employees with unnecessary information. While your business may be a bit too complex for a single-line handbook, the idea remains the same: Say what they need to know and say it quickly.

When thinking about handbooks, benefits information, onboarding materials, and basic information about the way the business functions probably come to mind. None of these topics are particularly engaging. To make things a little bit more interesting, some notable companies have opted for a more innovative employee manual design. This approach leaves the basic, boilerplate information out of the employee manual and instead offers that information digitally. For a small business, this approach might be a bit much. However, there is no reason a web-based employee manual can’t be an engaging mix of both aspirational brand values and informative policy information. Your handbook or manual should focus on helping the employee better understand the business, their role within it, and the company’s brand and values.

Employee manuals don’t need to be endless pages of boring corporate information. You are in control of what it contains. What do your employees need to know about working in your organization? What does it mean to be a part of your team? What is acceptable and unacceptable behavior? With a well-written employee handbook, you and your team will work together like a well-oiled machine so that your business can thrive and grow.

Originally published at https://policyco.io on January 17, 2020.

Employee Handbooks and Your Small Business was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

PolicyCo](https://f.hubspotusercontent40.net/hubfs/5557240/Imported_Blog_Media/screen-shot-2021-01-29-at-11-24-09-pm-1.png)

Policies and Procedures commonly need to reference other areas of policies. A great deal of planning went into this feature. Standard hyperlinks are inadequate because it’s not possible to view the information behind the link without navigating to it. Hyperlinks in PolicyCo have a “peek” feature that reveals the contents of the linked content inline. This benefits the end user by promoting continuity while disgesting information. In the example above, we have the word Encryption linked to another article. As you can see, the contents of the hyperlink are visible in a window when the user clicks on it. PolicyCo allows linking to articles and procedures internally and also allows off-site links on the web. PolicyCo makes it easy for your organization to quickly establish policies and procedures pre-mapped to HIPAA, SOC2 and HITRUST controls. We have an advanced editor with strict version control and a groundbreaking evidence gathering workflow engine.

Originally published at https://policyco.io on January 30, 2021.

Hyperlink Articles and Procedures was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’ve dealt with compliance frameworks, you understand that not every available control applies to your company. There may be controls that reference regional requirements or PCI compliance that don’t apply to your organization. HITRUST has a whopping 1800+ controls. We’ve made it incredibly easy to filter for classes of controls you don’t need and mark them as not applicable. If you need the control at a later time, it can be reactivated as well.

Originally published at https://policyco.io on February 24, 2021.

Bulk Control Management was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

We did it! Link your evidence-gathering activities to multiple external controls. This incredible feature allows you to carefully manage coverage of your evidence-gathering activities back to each relevant control.
Imagine gathering evidence a single time and satisfying multiple controls across multiple frameworks. This update will help you distribute the burden and ensure coverage. Our unique relational approach to managing internal controls, external controls, procedures, and evidence gathering is intuitive and efficient. Want to learn more about our compliance management software platform?

Originally published at https://policyco.io on July 15, 2021.

Link Evidence to External Controls was originally published in PolicyCo on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a new company that is being established, it is highly important you take into account your security measures. You should be doing several things when it comes to security, and I want to talk you through the top 3 things.

Know what you have — not just the laptops but all hardware, software, and, most importantly, the data. It’s not the price of a new laptop you should be worried about-It’s the cost of recovering from the loss of control of the data on that laptop if it’s stolen, lost, or hacked. Over time files and data tend to find their way into all corners within and sometimes outside your business. People make duplicate copies of files, folders, and databases in new folders or completely separate storage locations. With the advent of cloud and Software as a Service (SaaS) products (often with free versions available), the places your data can end up are only limited by your workforce’s imagination and the skill of SaaS product marketing teams. Do whatever you can now to establish good data handling, storage, and tracking practices for an early-stage company. Define the different levels of sensitive data you handle and how each will be maintained. Establish scheduled and recurring reviews to confirm that expectations are being met.

With internal and external people and systems accessing your systems and data from within and via the internet, being sure that whoever or whatever is granted access is who they should be is more important than ever. Access to your website you might be happy for anyone to see. But access to your source code repository, admin access to your applications, full edit rights access to the finance or HR files you want to be confident is only allowed after you have positively confirmed that it’s your VP of Engineering, your finance team, your HR Director as they claim to attempt to log in. Via LinkedIn, you can quickly learn the names of the finance office/team members for company X. A few guesses, and you can determine the email naming convention for the company. A password is harder to guess but not impossible. People are often tricked into giving up their passwords through social engineering attacks like email phishing. With those two pieces of information, an email address that, if not publicly available, is easily determined, and a password, something that can be guessed by a password cracking routine or captured through deception, an unauthorized user can gain access. By implementing Multi-Factor Authentication, adding at least one more element of identifying information, you complicate the process of gaining unauthorized access dramatically.

Make sure your people are aware of the threats, how to avoid opening the door for those threats, and how to detect a malicious attempt to compromise the security controls you work so hard to implement. Every employee, consultant, contractor, and partner of your business can be targeted to exploit weaknesses in your security program, so arm them with the knowledge to protect themselves and the company. Rather than emailing a once-a-year 40-page slide deck, mix up the delivery of cyber security tips and knowledge. A mix of short and catchy videos, newsletters, infographics, live briefings, interactive discussions, news bulletin emails, etc., delivered throughout the year will help make the information more exciting and fresh in the minds of your team.

Originally published at https://policyco.io on February 15, 2022.

Your roadmap to Flexibility, Repeatability, and Clarity.

The National Institute of Standards and Technology (NIST) seeks to advance measurement science, standards, and technology in ways that enhance economic security and improve our quality of life. The NIST Cybersecurity Framework is a standard developed and maintained by NIST to do just that, enhance economic security and improve quality of life.

The CSF was developed by the National Institute of Standards and Technology, a United States non-regulatory governmental agency housed under the Department of Commerce. Today, NIST standards are employed in fields from nanotechnology to cybersecurity. In 2013, NIST was tasked with developing a Cybersecurity Framework through an executive order and published version 1.0 of the Framework for Improving Critical Infrastructure Cybersecurity in February 2014. Version 1.1 was made available in April 2018. The CSF is one of NIST’s voluntary programs based on existing standards and guidelines and is developed with flexibility to help organizations better manage and reduce cybersecurity risk. The CSF is presented in a 48-page document that details different cybersecurity activities and desired outcomes that organizations can leverage for assessing an organization’s cybersecurity risk, risk maturity, and infrastructure around information security.

What is NIST CSF Used for?

The CSF has three major components — the framework core, implementation tiers, and profiles — designed to help you benchmark your organization’s risk maturity and prioritize actions you need to take to make improvements.

The 3 parts of the framework (Diagram 1)

Framework Core — A set of cybersecurity activities, desired outcomes, and relevant references common across critical infrastructure sectors. It consists of five concurrent and continuous Functions: Identity, Protect, Detect, Respond and Recover. Implementation Tier — Implementation tiers describe the degree to which an organization’s cybersecurity risk management practices exhibit the characteristics defined in the Framework, over a range from Partial (Tier 1) to Adaptive (Tier 4). Framework Profile — A framework profile represents the Core Functions’ Categories and Subcategories prioritized by an organization based on business needs and can measure the organization’s progress toward the Target Profile.

The 5 Core Functions (Diagram 2)

When considered together, the 5 Core Functions provide a strategic view of the lifecycle of an organization’s cybersecurity risk management and should be treated as a critical reference point. Here are the 5 Functions and how to comply with them:

Note: The Core Functions are intuitive and collectively with the Implementation Tiers and Profiles make for an easy-to-grasp blueprint that speeds adoption and provides ongoing guidance.

It is essential to understand that it is not a set of rules, controls, or tools. Instead, it offers a set of processes that can help organizations measure the maturity of their current cybersecurity and risk management policies, procedures, and practices and identify steps to strengthen them. The use of the NIST CSF offers multiple benefits. In particular, it can help you:

Gain a better understanding of your security risks Prioritize the activities that are the most critical Identify mitigation strategies Evaluate potential tools and processes Measure the ROI of cybersecurity investments Communicate effectively with all stakeholders, including IT, business, and executive teams

Adoption of the NIST CyberSecurity Framework provides a common, intuitive, and understandable language of risk-based security. Your technical, sales, customer support, executive, and finance teams will share the same understanding and terminology. NIST CSF enables an integrated risk management approach to cyber security management aligned with business goals. It provides a framework to align efforts across all departments to ensure that the risk management goals are set and met. When all departments understand the risks and work together, you have an organization in an excellent position to achieve its goals.

Cybersecurity risks are present in nearly every aspect of today’s technology-enabled businesses. Trying to keep up with them all and addressing them one by one is a recipe for competing priorities, inefficient allocation of resources, and burnout. The NIST CSF provides a risk-based approach to identify and understand your security landscape and then build a balanced and well-justified security roadmap. This integrated risk management approach enables the development and implementation of a cybersecurity management program aligned with business goals. The result is better communication, more effective decision-making throughout your organization, and well-informed and supported budgets. Adoption develops a common language for business and technical stakeholders alike, facilitating improved buy-in and success throughout the organization. PolicyCo provides a platform where cybersecurity maturity roadmaps for enterprises of all sizes are developed, implemented, monitored, and improved.

Framework for Improving Critical Infrastructure Cybersecurity and related news and information Cybersecurity resources within NIST

Originally published at https://policyco.io on February 1, 2022.

When I started the PolicyCo journey, I always focused on treating policy like we treat the agile process for software development. Being agile doesn’t mean the process is perfect, but it does allow for flexibility, transparency, and accountability. PolicyCo’s system stresses these qualities by having a documented and reportable workflow at each step of the process, including versioned commits, branch management, release candidates, code reviews, and limited role access for deployments. These are all important for the evolution of policy management.

Those responsible for writing policy aren’t programmers, and the concepts mentioned above can be overly technical. Balancing flexibility and usability is essential when applying programming concepts to policy management evolution. This is an effort to get my thoughts on paper to talk about how PolicyCo addresses this today and, more importantly, how we plan to close the loop in the future.

Some Background

Before getting into the details, it’s essential to understand that PolicyCo takes a unique approach to writing and ensuring compliance with policy. We believe that process is to break down the policy into articles. A policy is typically centered around a broad theme, regulation, or law. At the same time, the articles break down the specific requirements and business strategies into testable areas within that more general theme. Software developers don’t place all of their code into a single file; it’s a collection of files related to one another, each with a specific function. There is strength derived from adopting this mindset. Controls can be built specifically to each article mapped directly to the policy (e.g., security frameworks or federal regulations). These mappings ensure that the organization is testing for compliance at the granular level, ensuring accountability, and can be extended logically as your organization grows into new regulatory areas.

Versioned Commits

When developers commit code, they submit their changes to a central repository. Team members, with the proper permission, can see (a) the exact code that was committed, (b) the difference between the new and old code, © the exact time it was committed, and (d) the identity of the individual. In fact, not only can this information be viewed at the time of the commit, but it’s possible to go back in time to see the entire history of all commits from the beginning.

This same process can be used for versioning Policy. At the moment, PolicyCo requires users to (a) write/edit a draft article of a Policy, (b) submit it for review to the appropriate governance level, and then © publish it. This does provide accountability, but it’s clear we are still missing a step. If we were to compare this to a coding process, it most closely resembles a commit accepted through a PR (pull request). But just because a commit has been accepted via a PR doesn’t mean it’s ready for prime time. It’s essential to orchestrate multiple commits into a release and then deploy that release responsibly. So, for policy, that would mean understanding your organization’s governance process to ensure Policy updates are documented and approved by that structure. PolicyCo has developed a workflow that will work for any organization’s governance structure to ensure that each updated version of an article is incorporated into the policy and that the appropriate authority approves policy within your organization. Each stage of the review and approval process is viewable, documented, and reportable, including seeing prior versions.

Branch Management

In the software development world, we manage branches religiously. There are many philosophies but think of branches as parallel highway lanes that eventually merge into one. Following our logic above for draft articles, it is possible to change several articles within an overall policy. Under our current workflow, after the changes pass through the review and publish stages, it’s immediately effective; that is to say, it is now an active part of your new policy, however, to ensure your specific organization’s governance process is incorporated into our system, we are modifying the process to ensure that once the articles are modified, you have control to review and approve the policy in accordance with your organization’s governance process. Suppose you have a specific review date or period for reviewing and updating policies (whether due to a set time or update related to regulation or new law). In that case, our process will ensure that you are notified of the need to review and update the relevant articles. Once those articles have been updated and approved by your organization, the policy as a whole document will be ready for review, approval by your governing body, and then publication. This automated workflow process ensures that each article impacted by the change is reviewed and updated and the policy as a whole.

Release Candidates

We are actively planning to change the term published to approved. The reasoning here is that when an article reaches a published state, it’s still not ready to become public. We need another step to allow the manager to review approved articles and incorporate them into a new policy version for the appropriate governing body to approve the policy. Additionally, your organization may not want to publish immediately upon approval, so we’ve added the ability to specify an effective date for publication a policy. Drawing from software development, we plan to use minor versions (1.0.1) to indicate release candidates (article approvals) and major versions (1.1) to indicate policy releases.

Deployment

Deploying software involves gathering up commits that have passed muster and merging them into the main branch. A sophisticated framework called git makes it relatively easy to ensure that new code is responsibly introduced into production. Since we have defined approved articles as eligible commits, let’s follow the table below to understand how we can responsibly version policy over time, providing accountability for new content. For our example below, let’s assume that your current policy is version 1.0 with an effective date of 1/1/2022.

So, at this point, the effective policy is still 1.0, and we have two candidate policies ready for your organization’s governing body to approve:

As you can see, each policy candidate contains the cumulative changes from the minor versions generated as articles are approved. Since each candidate is cumulative, it’s only possible to promote the highest candidate version. At this point, it’s important to note that each organization may have different rules that need to be followed to promote a candidate to a release. Some may require board approval, while others may only require Manager level approval. Also, notably at the time of release, it’s essential to require an effective date to make crossover impossible. Document control ensures that two different versions of the same policy will not be active during the same period.

Let’s assume that we are ready to publish Policy 1.0.2. An authorized manager for the policy will select it from the list of candidates, ensure the appropriate approval has been obtained and set the publication release date. Your organization will have the ability to decide whether to name that version 1.1 or 2.0. The flexibility of our system ensures that you can choose whether to publish after an article (or articles) are approved or to ensure publication only after the whole policy has been approved. Following this, you may set the publication date immediately upon obtaining approval or an effective date set as far into the future as you like. Let’s make the following selections:

Policy version 1.1, Effective 2/1/2022

This policy will automatically take effect on the date chosen, in this case, February 1, 2022. The cycle will now start over, but now the baseline is version 1.1, and candidates will increment as 1.1.1, 1.1.2 until they are promoted to a new release Policy version. You will be able to see the prior version 1.0 and the draft articles 1.1.1 and 1.1.2, which have not yet been published, and 1.1, the new updated version Policy.

I hope this has been helpful. We haven’t completed this work yet and would be happy to hear from you if you have any questions or suggestions about modifying our approach to this process.

Originally published at https://policyco.io on January 13, 2022.