►
From YouTube: Understanding Compliance: Jeff Burrows
Description
The Compliance group at GitLab is experimenting with a video series that highlights compliance as a business function and the professionals who comprise these teams. Our hope is we can highlight the value added by these teams, help shift organizational mindsets about compliance, and find opportunities for GitLab to help improve their quality of life.
Jeff is a Security Compliance Manager at GitLab and has a great story to tell about "a day in the life" of being a compliance professional.
A
Cuter,
so
cool,
so
I'll
just
do
kind
of
a
brief
intro
to
let
you
know
so.
The
purpose
of
this
video
is,
I
want
to
be
able
to
do
a
couple
of
things.
I
want
to
help.
People
who
aren't
compliance
professionals
understand
what
it
is
that
you,
as
a
compliance
professional,
do
part
of
that
is
trying
to
articulate
through
anecdotal
experience
and
such
you.
A
Yeah
it's
sort
of
following
that.
That
tone
is
generally
trying
to
educate
around
how
compliance
is
a
mindset.
It's
not
necessarily
a
skill
set,
because
you
might
know
what
compliance
is
and
consists
of,
but
you
have
to
be
in
that
mindset
of
wanting
to
be
compliant
and
playing
your
role
whatever
that
might
be.
A
A
So,
with
all
of
that
said,
for
now,
what
I
just
want
to
do
is
walk
through
a
couple
of
questions
and
it'll
be
fairly
conversational.
I
don't
really
have
a
script
for
it.
I
just
want
to
pick
your
brain
and
give
you
that
opportunity
so,
first,
what
I
would
like
to
just
open
with
is:
can
you
tell
me
about
who
you
are,
what
your
role
is
at
get
lab
and
what
that
looks
like
day
to
day.
B
Sure
so
my
name
is
jeff
burrows,
I'm
a
security
manager
for
the
security
compliance
team
and
what
that
looks
like
day
to
day.
So
what
the
security
compliance
team
is
focused
with,
primarily
is
most
of
the
output
of
what
we
do
is
facilitating
external
audits.
That's
certainly
not
everything,
but
everything
tends
to
revolve
around
that
as
a
as
a
structure
in
terms
of
what
the
output
is.
So
a
lot
of
the
day-to-day
is
we're
testing
our
security
controls
against
a
variety
of
systems.
We're
looking
at
changes
to
the
industry
to
see.
A
B
A
A
So
he
actually
kind
of
answered
my
next
one.
So
let
me
skip
past
that,
so
I
think
what
would
be
helpful
is,
for
you
know,
particularly
get
lab
team,
but
also
customers.
What
are
the
current
certifications
we're
pursuing
if
you
can
disclose
that
and
then
whatever
you
can
disclose,
maybe
talk
a
little
bit
to
some
of
the
the
nuance
of
each
of
them
like
what
maybe
what
you
find
challenging
about
one
versus
the
other,
and
you
know
how
you're
kind
of
navigating
those
dynamics.
B
B
I
feel
like
security
compliance
tends
to
be
kind
of
front
loaded,
in
my
opinion,
where
it's
not
a
very
linear
relationship
between
one
head
count
for
one
certification
to
like
eight
head
count
with
eight
certifications
down
down
the
road
and
by
head
count.
I
mean
like
people
on
the
team,
so
I
think
that
you
know
you
need
a
lot
of
documentation
in
place
before
you
can
start
pursuing
security
certifications.
B
Within
that
context,
what
we've
done
is
we've
already
gone
through
the
sock,
2
type,
1
audit
and
the
so
sock
2
is,
is
becoming
more
of
an
industry
standard
as
just
like
a
general
assessment
of
the
the
relative
maturity
of
a
security
program,
not
incredibly
stingy.
Stringent
requirements
doesn't
represent
everything
that
we're
doing
from
a
perspective
of
security.
But
it's
a
good
holistic
view
of.
Are
you
considering
these
major
elements
that
should
be
in
place
with
a
a
reasonably
secure
program?
B
B
The
next
step
from
a
type
1
is
a
type
2
which
we're
going
to
be
kicking
off
the
the
field
work
for
in
the
next
couple
of
months
here
and
that's
a
period
of
time
assessment.
So
that's
going
one
step
further
to
say:
okay
with
these
controls
that
are
designed
effectively
to
support
security
within
gitlab.com,
how
do
they
actually
operate
over
a
period
of
time?
There's
a
long
lag
between
the
type
one
and
type
two,
because
the
minimum
period
you
can
assess
is
six
months,
and
so
you
need
to
get
everything
ready
front
load.
B
All
of
your
documentation
go
through
that
process
have
the
snapshot
to
say:
okay,
yes,
your
controls
are
designed
appropriately
and
then
you're
effectively
just
waiting
six
months,
while
your
controls
operate.
As
you
expect
them
to
so
that,
at
the
end
of
that
period,
they
can
go
back
and
retroactively.
Assess
is
that
is
that
happening.
B
So,
in
addition
to
sock
one,
I'm
sorry
in
addition
to
stock
two
type,
one
and
type
two
we
are
evaluating
the
business
case
for
fedramp.
We
know
that
there
are
a
lot
of
federal
customers
that
that
ask
us
about
fedramp
and
so
we're
putting
together
the
business
case,
because
it's
such
a
high
cost
and
unique
deployment
model.
There's
a
lot
of
considerations
there.
So
fedramp
is
top
of
mind
right
now
and
something
that
we're
we're
currently
evaluating.
B
Beyond
that,
our
intention
is
to
collect
a
portfolio
of
certifications
so
that
we'll
expand
the
scope
of
our
sock
to
audits,
we'll
go
past
iso
27001
and
and
continue
on
to
0018,
we'll
evaluate
the
the
feasibility
of
kind
of
more
region,
specific
security,
certifications
to
give
customers
confidence
in
those
areas.
So
the
intention
is
to
really
build
a
yeah,
a
portfolio
of
different
certifications
that
will
give
our
customers
that
assurance
that
we're
looking
at
this
through
various
lenses
of
scope
and
severity
and
and
we're
really
considering
our
security
program
very
holistically.
A
If
I'm
wrong
is
you
know,
you're
building
the
business
cases
to
say
if
we
have
to
choose
amongst
these
n
number
of
frameworks,
we're
going
to
go
with
these
y
number,
because
these
are
the
ones
that
are
going
to
best
support,
and
you
know
our
sales
teams
and
our
customer
success
and
acquiring,
but
retaining
customers
while
simultaneously
proving
that
we're.
You
know
we
have
this
strong
security
posture.
B
Yeah,
I
think
that's
absolutely
right,
I
think
so.
We
we
take
a
very
risk-based
approach
to
security
compliance
here
at
get
lab,
and
what
I
mean
by
that
is
everything
we
do
is
contextualized
within
trying
to
reduce
risk
to
to
get
lab
as
an
organization
within
the
context
of
what
we're
trying
to
accomplish
as
a
business
right,
because,
like
the
best
way
to
reduce
risk,
is
to
disconnect
everything
from
the
internet
and
have
it
just
sit
isolated
in
a
closet
somewhere.
B
So
it's
really,
you
know
we
want
to
understand
what
are
we
trying
to
accomplish
and
how,
within
the
context
of
yes,
we
want
to
help
the
business
accomplish
those
things
within
the
the
constraints
that
we
have.
How
can
we
reduce
risk
as
much
as
possible
to
provide
that
issuance
to
our
customers?
The
other
thing
I'll
add
there
is
just
that
we,
I
feel
confident
in
speaking
for
the
rest
of
the
security
compliance
team,
in
that
we
don't
approach
security,
compliance
as
a
way
to
accomplish
security.
B
Necessarily,
we
want
to
be
consumers
of
good
security,
best
practices.
We
don't
think
compliance
equals
security.
We
think
compliance
enables
security
to
scale
really
effectively,
and
so
we
we
like
to
defer
to
technical
experts
in
terms
of,
what's
the
best
way,
to
to
implement
technical
controls
to
reduce
that
risk.
A
Yeah,
that's
that's
a
a
really
good
way
to
articulate
that.
I
think
I
I'd
like
to
explore
that
just
a
bit
where
you
talk
about
you
know
relying
on
the
the
technical
experts,
because
I
think
traditionally
what
you
hear
is
these
anecdotes
or
these
stories
where
a
compliance
or
auditing
team
comes
in
and
says
it
has
to
be
done
this
way
or
or
they
try
to
be
prescriptive,
whereas
it
sounds
like
you're
doing
the
exact
opposite.
You
say:
hey,
we
have
these
controls.
We
know
we
need
to
meet.
A
B
Yeah,
I
would
definitely
say
that
it's
been
very
successful.
The
the
normal
relationship
between
security,
compliance
and
the
rest
of
security
tends
to
be
fraught,
certainly
not
at
all
organizations,
but
I
would
say
a
majority
of
organizations
that
I've
personally
worked
with,
because
you
have
people
who
just
are
under
too
much
work
and
they
they
want
to
prioritize
based
on
impact
to
the
organization.
B
B
A
B
Yeah,
you
know-
and
I
I
think
just
to
add
there
I
think,
we've
been
we've
been
very
deliberate
in
terms
of
how
we
very
consistently
communicate
that
message
of
we're
not
doing
this.
For
the
sake
of
doing
this
right,
we're
going
to
put
dollars
against
us
to
say
we
have
x
number
of
customers
coming
to
us
asking
us
about
these
certifications
and
that
that
validates
that
it's
it's
something
that
we
should
be
doing
as
an
organization,
because
it
supports
x
dollars
in
potential
revenue
or
you
know.
If
we
do
this,
we
won't
have
to
come.
B
Ask
you
for
each
individual
security
questionnaire.
We
can
you
know
we
can
defer
to
this
more
standard
methodology
that
will
allow
us
to
to
scale
since
we're
only
going
to
get
more
and
more
of
these
questionnaires,
and
I
think
the
other
thing
we've
done-
that's
been
really
successful
in
building
those
relationships
is
trying
to
provide
data
to
support.
B
I
guess
it
comes.
It
mostly
comes
down
to
resource
needs
for
other
teams.
Right
like
we
want
to
be
continually
testing
these
controls
and
preparing
for
external
audit,
and
so
we
can
point
to
gaps
and
processes,
and
so
there
are
times
where
we'll
have
multiple
observations,
which
is
the
output
of
our
of
our
testing
process
to
say,
hey
this
process
isn't
working
quite
the
way
we
intended
it
to,
or
I
think
we've
considered
the
this,
but
like
what
about
this
edge
case
we
might
need
to.
B
We
might
need
to
tune
this
process
or
or
this
technical
control,
to
consider
this.
This
this
other
scenario,
and
so
as
we
get
more
of
that
data
coming
out
of
that
that
process
and
that
program
we
can.
We
can
group
those
observations
by
team
and
then
we
can
go
to
somebody
like
infrastructure,
who
is
who
is
very,
very
overburdened
at
gitlab,
and
we
can
say:
hey.
We
have
all
these
findings
and
we
need
these
to
be
resolved
before
the
audit.
B
This
is
great
data
that
you
can
use
when
you're
planning
your
future
hiring
and
your
head
count
needs
to
say:
hey,
you
know,
there's
all
this
work
coming
in.
We
we
need
additional
support
and
so
we're
trying
to
consider
it's
not
only
value
to
our
customers,
it's
its
value
to
our
internal
stakeholders
as
well,
to
say,
hey,
you
know
like
we
want
to
give
you
the
data.
You
need
to
grow
your
team
appropriately
within
the
context
of
what
we're
trying
to
do
as
an
organization.
A
Yeah,
that's
that's
a
a
great
added
clarification
because
I
think
it
speaks
inherently
to
that
value
that
you're
adding.
So
thank
you
for
that.
I'd
like
to
get
your
opinion
on
for
somebody
who's
either
new
to
compliance,
or
maybe
you
know
it's
an
internal
team
member
that
you
want
to
help
them
shift
their
mindset
or
it's
maybe
a
seasoned
compliance
professional
who
is
maybe
coming
from
a
different
type
of
environment
and
you're,
trying
to
educate
them
on
maybe
the
gitlab
way,
because
you
find
that
it
works
really
well.
B
I've
seen
this
type
of
report
before
but
really
go
all
the
way
back
and
say:
what's
the
control
trying
to
achieve
and
have
that
lower
level
discussion,
which
might
take
a
little
bit
more
time
up
front
with
those
those
technical
counterparts,
because
then
you
get
those
really
rich
conversations
around,
like
you
know,
hey
infrastructure,
engineer,
I'm
looking
for
some
kind
of
firewall
report
review
right
and
that
that
leads
to
just
a
back
and
forth
of.
Why
do
you
need
this?
B
We
want
to
make
sure
that
we're
not
just
setting
these
firewall
rules
and
never
considering
whether
or
not
they
should
be
expiring,
whether
or
not
they
were
needed
three
years
ago
and
they're
no
longer
relevant.
So
we
want
to.
We
want
to
prove
to
an
auditor
that
we
holistically
consider
our
firewall
reviews
and
that
can
lead
to
to
a
better
conversation
around
well.
Okay,
so
here's
how
we
approach
it.
Here's
how
we
automate
it!
B
It
yields
much
much
better
results
where
we
can
be
consumers
of
what
they're
already
doing
and
we're
educating
ourselves
so
that
we
can
have
those
conversations
with
the
auditors
and
say:
okay,
you
might
be
used
to
seeing
this
type
of
review
evidence,
but
instead,
let's
talk
about
how
our
technology
is
set
up
and
let
me
show
you
some
configurations
of
the
automation
instead
and
it
accomplishes
the
same
result
but,
in
my
opinion,
a
much
more
scalable
way.
So
I
I
guess
what
I
would
say
to
them
is
just
like:
don't
go
to
the
here's.
B
A
Gotcha
yeah
thanks
for
that,
so
maybe
moving
towards
some
of
the
potential
like
product
insight.
Part
of
the
conversation
I'd
be
curious
to
understand
from
you.
What
what's?
Let's
just
say,
one
thing:
what
is
one
thing
that
no
application
does
well
when
it
comes
to
compliance
and
it's
a
bit
open-ended
for
you.
So
maybe
that's
in
terms
of
compliance
management,
maybe
that's
being
compliance
friendly
in
terms
of
the
application,
has
features
to
support
a
compliance,
a
good
compliance
posture.
But
what's
that
one
thing
that
you
think
nobody
does
well
right
now.
B
This
is
a
harder
question
for
me
just
because,
after
moving
into
management,
I
find
myself
working
less
on
the
on
the
day-to-day
stuff.
I
think
maybe
one
thing
is
from
my
perspective.
It
seems,
like
my
team
spends
a
non-trivial
amount
of
time,
validating
the
the
completeness
and
accuracy
of
data,
and
so
considering
not
just
what
the
output
is,
but
how
the
output
was
generated,
I
think
is,
is
maybe
one
of
one
of
the
biggest
things.
Because,
often
when
we
look
at
a
report,
we
want
to
know
how
is
that
report
pulled?
B
A
A
So
I
want
to
ask
maybe
just
one
question:
that's
you
know
maybe
a
little
bit
more,
even
more
so
open-ended
and
hopefully
a
little
bit
more
fun
for
you,
but
in
your
line
of
work
and
in
your
experience,
if
you
could
tell
kind
of
a
broader
audience,
let's
just
say
it's
the
team
members
at
gitlab,
if
you
could,
if
you
tell
them
one
thing,
you
wish
they
knew
about
your
job
in
compliance.
What
would
that
be?
And-
and
why
do
you
feel
it's
important
for
them
to
know
that.
B
Yeah,
I
don't
it's
a
really
good
question.
I
think
I
think
I
would
I
would.
I
would
try
and
explain
where
I
see
that
we
fit
in
kind
of
the
the
ecosystem
of
business
and
security
within
gitlab,
and
so
I
do
think
that
we're
trying
to
overcome
a
lot
of
stigma
around
check,
boxy
compliance,
people
and
unnecessary
requirements
that
that
aren't
as
applicable,
and
so
I
think
I
think
I
would
want
to
convey
that
we're
we're
serious
about
being
consumers
of
genuine
best
practices
and
we're
flexible.
B
That's
the
right
point
to
engage
security
compliance
because
we
want
to
be
in
on
those
decisions,
because,
ultimately,
our
goal
is
to
to
be
a
buffer
between
technical
experts
doing
what
what
they
know
and
love
and
external
auditors.
And
we
want
to
be
that
that
translator
service,
because
I
I
think
a
success
for
for
our
team
is
that
we're
reducing
as
much
as
possible
the
burden
of
an
audit
period.
A
Yeah,
that's
that's
a
great
answer.
I
I
think
that
you
again
touch
on
a
really
important
facet
there,
which
is
you
know
we're
trying
to
reduce
that
kind
of
like
oh
crap
moment
at
the
end,
where
it
might
seem
burdensome
and
it
might
seem
check
boxy
or
you
know
these
things
early
on,
but
it's
much
better
to
have
that
minor
inconvenience
every
so
often
versus
that
last
mile
stretch
at
the
very
end
where
everyone's
cramming
and
stressed
and
trying
to
deal
with
this
now
suddenly
large
burden
at
the
end.
B
No,
I
think
that's
right,
and
I
think
I
I
think
maybe
just
one
final
thought
is
we're.
One
thing
I
found
really
challenging
is:
what's
the
right
level
of
information
to
provide
to
people
to
support
the
requests
we're
making
of
them.
We
don't
want
to
go
all
the
way
down
and
say
here
are
the
individual
regulatory
or
compliance
framework
requirements,
and-
and
this
is
why
we're
asking
you
for
this
because
then
you're
just
you're
making
them
experts
at
our
job
instead
of
synthesizing
that
information
and
packaging
it.
B
But
at
the
same
time
you
don't
want
to
be
too
broad
to
say
just
trust
us.
We
know
what
we're
doing
give
us
this,
and
this
is
what
we
need
and
so
trying
to
find
that
sweet
spot
of
here's
our
request.
Here's
how
this
request
supports
these
controls
and
these
requirements,
if
you're
interested
but
but
abstracting,
that
to
a
point
where
it's
comprehensible
and
not
burdensome,
I
think
is,
is
something
that
we've
definitely
struggled
with.
So.
A
Yeah
that
all
makes
perfect
sense
to
me
and-
and
hopefully
this
conversation
will
be
helpful,
for
you
know
non-compliance
and
compliance
alike,
to
see
how
you
know,
we've
had
some
successes
and
shared
in
some
of
the
struggles
and
hopefully
make
for
a
much
better
experience
overall
for
everyone,
but
jeff
thanks
so
much
this
was.
This
is
really
great.
I
enjoyed
this
format.
I
hope
you
did
too
any
kind
of
final
thoughts
or
maybe
advice
for
the
next
one.